Be careful using xerces 2.2.0. There seems to be several bugs in the formal release. Here is one that bit me: DOMParser features do not have any effect http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13044
I would recommend waiting for 2.2.1 or use the jar files from http://gump.covalent.net/jars/latest/xml-xerces2/ Just my $0.02, David Janovy -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 3:19 PM To: Log4J Developers List Subject: RE: DomConfigurator Entity Resolver update There was a mistake in my tests, although the previously reported results still hold -- almost. First, the mistake. I was using ant 1.4 instead of 1.5. However, the log4j unit tests with ant 1.5 ran fine (as reported previously). Now, the new result: replacing xerces 2.2.0 with 2.1.0 causes the following error: DOM: [junit] Running org.apache.log4j.xml.DOMTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.04 sec [junit] Testsuite: org.apache.log4j.xml.DOMTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.04 sec [junit] Testcase: test1 took 0.04 sec [junit] Caused an ERROR [junit] org/w3c/dom/Node [junit] java.lang.NoClassDefFoundError: org/w3c/dom/Node [junit] at org.apache.log4j.xml.DOMTestCase.test1(DOMTestCase.java:56) [junit] Testcase: test1 I am convinced that the org.w3c.dom.Node class is available in ant-1.5.1/lib, as indicated by the following command: /java/jakarta-ant-1.5.1/lib# jar tvf xmlParserAPIs.jar |grep 'org.w3c.dom.Node.class' 1630 Tue Aug 27 15:54:40 CEST 2002 org/w3c/dom/Node.class Can you reproduce this error? Paul is this the error you were observing? As far as I can see, we have a problem with xerces 2.1.0 that goes away in 2.2.0. Moreover, the resulting error message *appears* unrelated to the EntityResolver issue that brought up all this. At 23:51 08.10.2002 +0200, you wrote: >No, 2.2.0. I'll try with 2.1. > >At 14:15 08.10.2002 -0700, you wrote: >>Using xerces 2.1? >> >>-Mark >> >> > -----Original Message----- >> > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >> > Sent: Tuesday, October 08, 2002 2:14 PM >> > To: Log4J Developers List >> > Subject: RE: DomConfigurator Entity Resolver update >> > >> > >> > >> > I ran the log4j unit with ant 1.5.1 and the modified class >> > path using >> > log4j-1.2.6.jar instead of the log4j class files. It all ran >> > without a hitch. >> > >> > At 23:02 08.10.2002 +0200, you wrote: >> > >> > >I think the trick is to use a different class loader settings. >> > > >> > >Instead of >> > > >> > ><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> >> > > >> > >use >> > > >> > ><path id="tests.classpath"> >> > ><pathelement location="${log4j.jar}"/> <--- this is the change >> > ><pathelement location="${tests.source.home}"/> >> > ><pathelement location="./classes"/> >> > ><pathelement location="./resources"/> >> > ><pathelement location="${jakarta.oro.jar}"/> >> > ></path> >> > > >> > >Of course you would need to change the parser used by ant as >> > well. I'll >> > >try this is a sec and report back the reults. >> > > >> > > >> > >At 13:28 08.10.2002 -0700, you wrote: >> > >>Hm. So, how would I simulate this in a test case. Any ideas? >> > >> >> > >>-Mark >> > >> >> > >> > -----Original Message----- >> > >> > From: Paul Austin [mailto:[EMAIL PROTECTED]] >> > >> > Sent: Tuesday, October 08, 2002 9:53 AM >> > >> > To: Log4J Developers List >> > >> > Subject: RE: DomConfigurator Entity Resolver update >> > >> > >> > >> > >> > >> > I have just written a simple test harness as well and when >> > >> > running the tests >> > >> > using log4j 1.2.6 there are no errors. But when we run >> > >> > similar code (diff >> > >> > package) from within our application it cannot find the dtd. >> > >> > I think what is >> > >> > happening here is that in our application we have a dynamic >> > >> > classloader that >> > >> > will load the jar files including log4j from the lib >> > >> > directory after the jvm >> > >> > has booted up (similar to what jboss does). I think it is in >> > >> > the scenario >> > >> > that xerces fails to find the log4j.dtd. >> > >> > >> > >> > Regards, >> > >> > Paul >> > >> > >> > >> > -----Original Message----- >> > >> > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >> > >> > Sent: October 8, 2002 9:02 AM >> > >> > To: Log4J Developers List >> > >> > Subject: RE: DomConfigurator Entity Resolver update >> > >> > >> > >> > >> > >> > >> > >> > I'll give it a shake to see if I observe anything different. >> > >> > >> > >> > At 08:33 08.10.2002 -0700, you wrote: >> > >> > >The build.bat that I created to build the src explicitly >> > >> > lists which jars >> > >> > to >> > >> > >include in the classpath when invoking ant (it is not the >> > >> > version that >> > >> > >builds up the classpath dynamically from the lib dir >> > >> > contents). I replaced >> > >> > >jaxp.jar and crimson.jar in this classpath with >> > xercesImpl.jar and >> > >> > >xercesXmlApis.jar. Using either versions 2.1 or 2.2, I do >> > >> > not get any >> > >> > >failures during the unit tests. So, either something is >> > >> > going on I don't >> > >> > >understand (and after the Tomcat/jar loading fiasco, it is >> > >> > possible) or the >> > >> > >test cases do not exercise the parser in such a way to cause >> > >> > a failure. >> > >> > > >> > >> > >One difference might be that the log4j code is used in class >> > >> > directory >> > >> > >format instead of from a build jar? I don't see why it >> > would make a >> > >> > >difference. >> > >> > > >> > >> > >-Mark >> > >> > > >> > >> > > > -----Original Message----- >> > >> > > > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] >> > >> > > > Sent: Tuesday, October 08, 2002 12:43 AM >> > >> > > > To: Log4J Developers List >> > >> > > > Subject: RE: DomConfigurator Entity Resolver update >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > 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.(tm) >> > >> > > > >> > > > [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]> >> > >> > > > >> > >> > > >> > >> > >-- >> > >> > >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]> >> >> >> >> >> >> >> >> >> >>-- >> >>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]> >> >>-- >>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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
