One thing to note. Ant-1.5.1 ships with Xerces-2.2.0 (XercesImpl.jar) and xml-apis.jar, version 1.0b2, from the xml.apache.org commons project. The reason for the latter is that it includes a full version of JAXP where, apparently, Xerces xmlParserAPIs.jar ships with only half of JAXP. The Ant developers wanted to be complete. You can see all the version info for yourself if you read the README file $ANT_HOME/lib. And, BTW, there are a few ongoing bugs in Tomcat related to using Xerces-2.2.0 that weren't happening with Xerces-2.1.0. I guess the reason is that they tightened up spec compliance. This may be what we are seeing here. Not sure if you wanted to know that, but I thought I'd mention it.
See: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13282 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13241 Jake At 09:43 AM 10/8/2002 +0200, you wrote: >There is another way of course. One can simply replace the jar files >in jakarta-ant-1.x/lib with the jar files of the desired parser. > >At 09:34 08.10.2002 +0200, you wrote: >>That is correct. Here are the contents of my jakarta-ant-1.4/lib >>directory: >> >>/java/jakarta-ant-1.4/lib# ls -la >> 0 May 9 10:12 . >> 0 Feb 16 2002 .. >> 153 Sep 3 2001 README >> 416389 Sep 3 2001 ant.jar >> 196399 Sep 3 2001 crimson.jar >> 468524 Feb 22 2002 jakarta-ant-1.4-optional.jar >> 33323 Sep 3 2001 jaxp.jar >> >>As you can see in contains crimson.jar and jaxp.jar. These are visible >>to the ant classloader which if I recall correctly is the parent of >>the classloader that deals with: >> >> <path id="tests.classpath"> >> <pathelement location="${project.source.home}"/> >> <pathelement location="${project.classes.home}"/> >> <pathelement location="${tests.source.home}"/> >> <pathelement location="./classes"/> >> <pathelement location="./resources"/> >> <pathelement location="${jakarta.oro.jar}"/> >> </path> >> >>(The above is from log4j-1.2.x/tests/build.xml). >> >>So I guess that XML parser shipped with ant hides the parser you are >>trying to use. We can either try to fully understand the ant >>classloading model or simply use both ant 1.4 and ant 1.5, the latter >>ships with xerces2.... >> >>At 23:49 07.10.2002 -0700, you wrote: >>>No error is reported using Xerces 2.1.0 with the test cases either... >>> >>>Unless there is something up with the classpath that is used with the JUnit >>>tests. We don't specify any xml parser in the classpath reference in the >>>test case build.xml, so I am assuming that it is inheriting the ant >>>classpath as well as the classpath reference when running the JUnit task...? >>> >>>-Mark >>> >>> > -----Original Message----- >>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >>> > Sent: Monday, October 07, 2002 11:43 PM >>> > To: Log4J Developers List >>> > Subject: RE: DomConfigurator Entity Resolver update >>> > >>> > >>> > Paul, >>> > >>> > Can you send me a sample xml file that causes the current >>> > DOMConfigurator to >>> > fail using Xerces 2.2? The test cases we have right now, there is no >>> > failure thrown when using Xerces 2.2. They have a DOCTYPE definition >>> like >>> > this: >>> > >>> > <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> >>> > >>> > thanks, >>> > -Mark >>> > >>> > > -----Original Message----- >>> > > From: Paul Austin [mailto:[EMAIL PROTECTED]] >>> > > Sent: Monday, October 07, 2002 8:45 AM >>> > > To: Log4J Developers List >>> > > Subject: RE: DomConfigurator Entity Resolver update >>> > > >>> > > >>> > > Mark, >>> > > >>> > > The orginal code returned the log4j dtd if the filename in the >>> > dtd started >>> > > with file: and ended with log4j.dtd. This worked with xerces2.1 >>> > but failed >>> > > to work with xerces2.2 as the url with 2.2 was just log4j.dtd. So >>> > > I changed >>> > > the check to look just for a url ending in log4j.dtd. >>> > > >>> > > Paul >>> > > >>> > > -----Original Message----- >>> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >>> > > Sent: October 3, 2002 11:21 PM >>> > > To: Log4J Developers List >>> > > Subject: RE: DomConfigurator Entity Resolver update >>> > > >>> > > >>> > > Paul, >>> > > >>> > > Thanks the the patched patch :-). Can you describe what problem the >>> > > original version caused? >>> > > >>> > > I'm still going to look at applying the patch...soon... >>> > > >>> > > thanks, >>> > > -Mark >>> > > >>> > > > -----Original Message----- >>> > > > From: Paul Austin [mailto:[EMAIL PROTECTED]] >>> > > > Sent: Wednesday, October 02, 2002 4:32 PM >>> > > > To: [EMAIL PROTECTED] >>> > > > Subject: DomConfigurator Entity Resolver update >>> > > > >>> > > > >>> > > > Guys, >>> > > > >>> > > > I found a bug in the bug fix which stopped it working, the >>> > file attached >>> > > > fixes this problem. >>> > > > >>> > > > Paul Austin >>> > > > Galdos Systems Inc. >>> > > > [EMAIL PROTECTED] >>> > > > Tel: +1 (604) 484-2761 >>> > > > Fax: +1 (604) 484-2755 >>> > > > http://www.galdosinc.com/ >>> > > > >>> > > > Privileged or confidential information may be contained in this >>> > > > message. If >>> > > > this message was not intended for you, destroy it and notify us >>> > > > immediately. >>> > > > Opinions, conclusions, recommendations, and other information >>> > > presented in >>> > > > this message are not given or necessarily endorsed by my >>> > > employer or firm. >>> > > > >>> > > > >>> > > >>> > > >>> > > -- >>> > > To unsubscribe, e-mail: >>> > <mailto:[EMAIL PROTECTED]> >>> > For additional commands, e-mail: >>><mailto:[EMAIL PROTECTED]> >>> >>> >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >>-- >>Ceki >> >>TCP implementations will follow a general principle of robustness: be >>conservative in what you do, be liberal in what you accept from >>others. -- Jon Postel, RFC 793 >> >> >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >-- >Ceki > >TCP implementations will follow a general principle of robustness: be >conservative in what you do, be liberal in what you accept from >others. -- Jon Postel, RFC 793 > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
