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