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]
