I found my problem. I looked at the DOMConfigurator code. The resolver
is set when the configure(Element el) is not used. I went back to my
code and sure enough I was using configure(root). Duh, user abuser.
I apologize for any confusion.
-S
On Jul 29, 2005, at 12:14 PM, Steve Pruitt wrote:
> That's very interesting. It's a good day when you learn something.
> If I understand, I do not need to include a dtd; it is fetched from
> the log4j jar.
>
> When and where does the the resolver get registered? This may very
> well be something I prevent from doing so.
>
It will be in one of the o.a.log4j.xml.DOMConfigurator.doConfigure()
methods (will have just moved in 1.2.12rc1). Search src/java/org/
apache/log4j/xml/DOMConfigurator.java for EntityResolver and you will
find it.
> Setting a breakpoint will be nay impossible. But, I could - dare I
> say
> - try and place some System.out's.
I'd start with o.a.l.xml.Log4jEntityResolver. If it is getting to the
resolveEntity method, the most likely failure would be due to something
going wrong with the getResourceAsStream method. If the method returns
null, then the XML parser will attempt to find the dtd on the
file-system. That could be prevented by returning an empty
ByteArrayInputStream which would eliminate the fatal error and result in
a lot of validation warnings.
if (in == null) {
LogLog.error("Could not find [log4j.dtd]. Used [" +
clazz.getClassLoader()
+ "] class loader in the search.");
- return null;
+ return new InputSource(new java.io.ByteArrayInputStream(new byte
[0]));
}
The downside is that someone who had a class loader problem, but had
placed the DTD in the expected spot would now get a lot of warnings.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
