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