cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: Build failure because of proxy-firewall
Date Wed, 26 Nov 2003 12:48:59 GMT
David Crossley wrote:
> Geoff Howard wrote:
>>Timothy Larson wrote:
>>>I just downloaded a new snapshot, and now the build fails with this message:
>>>UnknownHostException.  Probable cause: The parser is trying to resolve a dtd from
the internet
>>>and no connection exists. You can either connect to the internet during the build,
or patch
>>> to ignore DTD declarations when your parser is in use.
>>>My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated
>>>proxy-firewalled network.  A quick look through did not enlighten
>>>Any clues how to get the builds working again without requiring a network connection?
>>I wrote that overly verbose message for just such an occasion as this! 
>>     The XConfToolTask (in tools/src/anttasks or used to be) was using a 
>>parser-specific setting to force it to not resolve dtd references.  The 
>>line is:
>>                 new Boolean(false));
>>So, either the latest version of the XML libs committed recently by 
>>Antonio (this would be Xerces, no? I can never remember which X is 
>>which!) has changed this behavior, or something in the latest changes to 
>>support property expansion have broken it.
>>The first seems way more likely and may be documented at 
>>in release notes.  Unfortunately, don't have time to look into it myself.
> Why would XConfToolTask be trying to go onto the network anyway?
> What DTD is it trying to get? Oh i see, it is trying to deal with
> web.xml which points to a DTD at Sun.
> There is an attempt to use XMLCatalog in XConfToolTask. Perhaps we
> just need to add some configuration for a local copy. I vaguely
> recall investigating this before, but i think that i got frightened
> by Sun's conditions in the DTD license (the "not without written
> authorisation" thing). is where we 
discussed the issues.  I think (though I only scanned the archive this 
time) that we decided there _probably_ was a licensing issue (I could 
swear someone eventually chimed in more definitively but can't find it 
ATM) but that configuring to not resolve external DTD was enough for 
this use anyway.  Now that's broken but it isn't clear why yet so 
discussing another solution is probably premature.

Can someone try rolling back Xerces to prior version to make sure that's 
the issue?  Of course, you'll have to unplug from the network before 
building or you won't notice the issue.  I looked briefly at Xerces' 
site last night and didn't find any clues this was intentionally changed 
in the latest release but there were some bugfix descriptions which 
could point to an accidental new problem.


View raw message