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]>
