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