Hello Curt,
Where were you 3 years ago? Your tip would have been really helpful.
To give you some background, if you look at DOMConfigrator you should see that we are using a custom entity resolver. The problem we are currently facing is more involved than that. In previous versions of log4j, the DTD was mandatory. In 1.3 it is not needed. In order to remain compatible with existing XML config files Joran made use of a custom entity resolver. Now, Crimson (Sun's parser shipped with JDK 1.4) refuses to look at a file with a system id of "log4j.dtd" saying that it is not a valid URL, ignoring our custom entity resolver in the process. In contrast, xerces correctly delegates the resolution of the system id to our custom resolver.
There are tricks to fool Crimson into thinking that "log4j.dtd." is a valid URL. Unfortunately those tricks force the existence of a DTD which we don't want. Anyway, this was explained in previous messages.
Does this make better sense?
At 04:43 AM 11/30/2004, Curt Arnold wrote:
It should be possible to provide the needed DTD (for parsers that demand it) by embedding a copy of log4j.dtd within the log4j.jar file, creating a class that implements org.xml.sax.EntityResolver and have its' resolveEntity method return an InputSource that contains a stream from the resource when the system ID is log4j.dtd. Should work with all JAXP compatible parsers.
Pretty simple, if you can't take it from there, I can do it in a day or two.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
