This change should eliminate the need to provide logger.dtd with no
degradation of behavior (actually should be a tad faster).
On Aug 23, 2007, at 12:07 PM, [EMAIL PROTECTED] wrote:
Author: carnold
Date: Thu Aug 23 10:06:59 2007
New Revision: 569073
URL: http://svn.apache.org/viewvc?rev=569073&view=rev
Log:
Eliminate need to resolve logger.dtd
Modified:
logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingEntityResolver.java
logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingXMLDecoder.java
Modified: logging/log4j/companions/receivers/trunk/src/main/java/
org/apache/log4j/xml/UtilLoggingEntityResolver.java
URL: http://svn.apache.org/viewvc/logging/log4j/companions/
receivers/trunk/src/main/java/org/apache/log4j/xml/
UtilLoggingEntityResolver.java?
rev=569073&r1=569072&r2=569073&view=diff
======================================================================
========
--- logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingEntityResolver.java (original)
+++ logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingEntityResolver.java Thu Aug 23 10:06:59
2007
Basically any request for logger.dtd will get you an empty
InputSource (just like the file was there but empty). Sun's
logger.dtd does not contain any default attribute values which would
be the only thing a DTD would provide when validation is disabled
(like it is in UtilLoggingXMLDecoder).
Modified: logging/log4j/companions/receivers/trunk/src/main/java/
org/apache/log4j/xml/UtilLoggingXMLDecoder.java
URL: http://svn.apache.org/viewvc/logging/log4j/companions/
receivers/trunk/src/main/java/org/apache/log4j/xml/
UtilLoggingXMLDecoder.java?rev=569073&r1=569072&r2=569073&view=diff
======================================================================
========
--- logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingXMLDecoder.java (original)
+++ logging/log4j/companions/receivers/trunk/src/main/java/org/
apache/log4j/xml/UtilLoggingXMLDecoder.java Thu Aug 23 10:06:59 2007
@@ -63,8 +63,7 @@
* Document prolog.
*/
private static final String BEGIN_PART =
- "<?xml version=\"1.0\" encoding=\"UTF-8\" ?>"
- + "<!DOCTYPE log SYSTEM \"logger.dtd\"><log>";
+ "<log>";
The encoding is meaningless when parsing from a String. I really
doubt that anything would encounter the differences between XML 1.0
and 1.1 which are very esoteric. Adding the DOCTYPE only adds
useless overhead since validation is disabled and the DTD provides no
default values. If it were to stay, the URL should be changed to a
absolute URL since the parser is going to be helpless to resolve
logger.dtd relative to a String (and some parsers attempt to resolve
the URL before passing to the entity resolver).
/**
* Document close.
*/
@@ -163,7 +162,6 @@
InputSource inputSource =
new InputSource(new StringReader(buf.toString()));
- inputSource.setSystemId("dummy://logger.dtd");
Setting the SystemID for the input source was a kludge to resolve the
relative URL for the DTD. Similar code needed to be removed in the
XMLDecoder since some parsers check that the URL scheme is recognized.
document = docBuilder.parse(inputSource);
} catch (Exception e) {
e.printStackTrace();
The code still has some remaining issues. The code that checks
whether the source needs to be wrapped in start and end tags have
holes (for example if the closing </log> tag is followed by
whitespace then a stray extra </log> tag will be added). A more
robust way to do would be to parse something like:
<DOCTYPE log [
<!ENTITY body SYSTEM 'http://localhost/body.xml'>
<log>
&body;
</log>
and provide an EntityResolver that substitutes the string for
body.xml. If you actually had a <log> element in your source, then
you would need to post-process the DOM document to move the second
level log element up to the top.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
