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.™
>> > > > [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]>

Reply via email to