Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Joerg Heinicke <jo...@gmx.de>]

On 02.03.2004 22:08, Geoff Howard wrote:

>>>> Hi,
>>>>
>>>> Most of the time when I run XConfToolTask, it works
>>>> fine, but sometimes I get the following error:
>>>>
>>>> IOException: java.net.ConnectException: Connection
>>>> timed out: connect
>>>>
>>>> Any idea what's the problem here?
>>>
>>>
>>>
>>> Which version of Cocoon?  The xpatch task is supposed to disable 
>>> resolving of remote dtds but the underlying xalan/xerces feature was 
>>> broken.  To be honest, I don't remember where it left off, when it 
>>> broke or if/when it was fixed.
>>
>>
>>
>> It was Xerces 2.6.0, but fixed for Cocoon 2.1.4.
> 
> Thanks, Joerg.  I had it in my head that it was "fixed" but the problem 
> didn't go away.  Am I loonier than I thought?

The problem after an upgrade is the remaining of the xerces JAR at 
tools/lib. The JARs are only copied on demand to that place, i.e. if no 
xerces JAR exists at that place at all. If there is already a 2.6.0 JAR 
it won't be replaced if you have updated only lib/endorsed. This is at 
least true for build.bat. build.sh copies the endorsed libs always to 
tools/lib, but does not remove old versions.

Is that explanation helpful?

Why are these three files copied at all? When the java.endorsed.dirs 
property is set (which is to lib/endorsed) the JARs are on the 
classpath. If we need to copy them the build script should probably made 
a bit more intelligent on this issue.

Joerg

Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Joerg Heinicke <jo...@gmx.de>]

On 02.03.2004 22:51, Geoff Howard wrote:

>> The problem after an upgrade is the remaining of the xerces JAR at 
>> tools/lib. The JARs are only copied on demand to that place, i.e. if 
>> no xerces JAR exists at that place at all. If there is already a 2.6.0 
>> JAR it won't be replaced if you have updated only lib/endorsed. This 
>> is at least true for build.bat. build.sh copies the endorsed libs 
>> always to tools/lib, but does not remove old versions.
>>
>> Is that explanation helpful?
>>
>> Why are these three files copied at all? When the java.endorsed.dirs 
>> property is set (which is to lib/endorsed) the JARs are on the 
>> classpath. If we need to copy them the build script should probably 
>> made a bit more intelligent on this issue.
> 
> 
> No fair, I figured that out on my own but now you won't believe me... :)
> 
> I have no idea why the build copies those files, and I think no one 
> does.  Anyone?  In fact, the batch file spits out bogus file not found 
> warnings at the beginning of every build which has confused newbies.

Yes, the windows build tests for many locations where to find the JARs.

> Anyone against stopping the copy from lib/endorsed to toos/lib, and 
> pointing the ant/jetty endorsed dir to lib/endorsed directly?

The java.endorsed.dirs already point to lib/endorsed.

>  If not, 
> then we need to fix the build scripts so that we are not shielded from 
> endorsed lib updates in the build.

It's just an issue of the build. I tried it without the libs at 
tools/lib and it does not work:

BUILD FAILED
java.lang.IllegalArgumentException: No attributes are implemented
         at 
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.setAttribute(Docum
entBuilderFactoryImpl.java:93)
         at XConfToolTask.execute(Unknown Source)

Hmm, don't know why it falls back to Crimson (from JDK I guess) though 
endorsed dirs are set and Ant works without the JARs in tools/lib.

Joerg

Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Geoff Howard <co...@leverageweb.com>]

Joerg Heinicke wrote:

> On 02.03.2004 22:08, Geoff Howard wrote:
>
>>>>> Hi,
>>>>>
>>>>> Most of the time when I run XConfToolTask, it works
>>>>> fine, but sometimes I get the following error:
>>>>>
>>>>> IOException: java.net.ConnectException: Connection
>>>>> timed out: connect
>>>>>
>>>>> Any idea what's the problem here?
>>>>
>>>>
>>>>
>>>>
>>>> Which version of Cocoon?  The xpatch task is supposed to disable 
>>>> resolving of remote dtds but the underlying xalan/xerces feature 
>>>> was broken.  To be honest, I don't remember where it left off, when 
>>>> it broke or if/when it was fixed.
>>>
>>>
>>>
>>>
>>> It was Xerces 2.6.0, but fixed for Cocoon 2.1.4.
>>
>>
>> Thanks, Joerg.  I had it in my head that it was "fixed" but the 
>> problem didn't go away.  Am I loonier than I thought?
>
>
> The problem after an upgrade is the remaining of the xerces JAR at 
> tools/lib. The JARs are only copied on demand to that place, i.e. if 
> no xerces JAR exists at that place at all. If there is already a 2.6.0 
> JAR it won't be replaced if you have updated only lib/endorsed. This 
> is at least true for build.bat. build.sh copies the endorsed libs 
> always to tools/lib, but does not remove old versions.
>
> Is that explanation helpful?
>
> Why are these three files copied at all? When the java.endorsed.dirs 
> property is set (which is to lib/endorsed) the JARs are on the 
> classpath. If we need to copy them the build script should probably 
> made a bit more intelligent on this issue.


No fair, I figured that out on my own but now you won't believe me... :)

I have no idea why the build copies those files, and I think no one 
does.  Anyone?  In fact, the batch file spits out bogus file not found 
warnings at the beginning of every build which has confused newbies.

Anyone against stopping the copy from lib/endorsed to toos/lib, and 
pointing the ant/jetty endorsed dir to lib/endorsed directly?  If not, 
then we need to fix the build scripts so that we are not shielded from 
endorsed lib updates in the build.

Geoff