Hi Mark,
Maybe we should look at the fix I provided in a different way as we have
been unable to replicate it due to me not remembering the environment that
caused the problem.
If we look at the current code in DOMConfigurator.java:670 we see the
following, where the inputSource is the contents of the log4j.xml file.
inputSource.setSystemId(dtdURL.toString());
If we look at the javadoc comment from the org.xml.sax.InputSource package
it basically says, if the inputsource has an inputstream/reader this will be
used to load the DOCUMENT otherwise the systemId will be used as a url to
load the DOCUMENT.
<quote>
The SAX parser will use the InputSource object to determine how to read XML
input. If there is a character stream available, the parser will read that
stream directly, disregarding any text encoding declaration found in that
stream. If there is no character stream, but there is a byte stream, the
parser will use that byte stream, using the encoding specified in the
InputSource or else (if no encoding is specified) autodetecting the
character encoding using an algorithm such as the one in the XML
specification. If neither a character stream nor a byte stream is available,
the parser will attempt to open a URI connection to the resource identified
by the system identifier.
</quote>
So from this definition as we have set the inputstream/reader on the input
source the parser should not even look at the systemId and it should
definately not be expecting the systemId to be used to find the dtd.
With JAXP both sax and dom the org.xml.sax.EntityResolver is the approved
and supported way to load a local copy of the dtd and to give the parser an
InputSource for that dtd when it needs it.
The way the EntityResolver is normally implemented it either looks at the
systemId parameter (i.e. log4j.dtd) or the publicId (i.e. -//Apache Software
Foundation//DTD Log4j 1.2//EN) and loads the appropriate stream to the dtd
and returns it as an input source.
Regards,
Paul
P.S. The dtd definition used was as per the examples from log4j, see below.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";
debug="false">
<appender name="Console" class="org.apache.log4j.ConsoleAppender">
<param name="Threshold" value="ERR"/>
<param name="Target" value="System.out"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d\t%p\t%c\t%m%n"/>
</layout>
</appender>
<root>
<appender-ref ref="Console"/>
</root>
</log4j:configuration>
-----Original Message-----
From: Mark Womack [mailto:[EMAIL PROTECTED]]
Sent: October 9, 2002 2:00 PM
To: 'Log4J Developers List'
Subject: RE: DomConfigurator Entity Resolver update
Paul,
Is it possible that your configuration file had/has a different value for
"log4j.dtd" in the DOCTYPE?
-Mark
> -----Original Message-----
> From: Paul Austin [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 3:30 PM
> To: Log4J Developers List
> Subject: RE: DomConfigurator Entity Resolver update
>
>
> Guys,
>
> The original error was reported in the following bug
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12366 which
> shows the
> stack trace from someone else's application. The error below
> was the same as
> the one I was receiving.
>
> log4j:ERROR Could not parse input source
> [org.xml.sax.InputSource@cd107f].
> java.net.MalformedURLException: no protocol: log4j.dtd
> at java.net.URL.<init>(URL.java:579)
> :
> <snip>
> :
> at
> org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuild
> erImpl.java:20
> 1)
> at
> org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurat
> or.java:672)
>
> I have tried to reproduce the error again but can't get our
> application back
> to the same set of libraries that produced the orginal
> problem, with lots of
> trying today (I knew I should have designed a test case at
> that point).
>
> Anyway the approach provided in the fix is the correct way to
> look up a dtd
> using the JAXP apis and should be supported by all parsers.
>
> Also as mentioned before using this approach you can start to
> support using
> a public id for the log4j.dtd file.
>
> Paul
>
>
> --
> 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]>
