On Aug 7, 2007, at 5:23 PM, Paul Smith wrote:
On 08/08/2007, at 7:22 AM, Curt Arnold wrote:
The log4j 1.2 layout can produce non well formed content for some
atypical content (a message with an embedded -->, threads
containing & or >, etc). Plus it does not output MDC content
(log4j 1.3 does, but shares the other shortcomings). I've been
tempted to overhaul it but am hesitant to break code that might
have compensated for its idiosyncracies. My current thought is to
add an XsltAppender to the extras companion that uses the xslt
support added in idk 1.4. If no transform is provided, a default
transform that results in a format compatible with the current
output but done right. If you wanted some other format, you could
embed the xslt transform if you were using log4j 1.2.15 or higher
or the replacement configurator in the extras companion.
Hmm, this is a tough one. If we think (and I don't know myself, I
don't use XMLLayout at all) that these are really bugs, then we
should feel free to address them and note in the release notes that
this might be an incompatible change if people have relied on that
odd behavior.
Sorry, I know that there are a decent number of potential issues with
the existing XMLLayout, but the ones I listed may or may not actually
be issues. I was trying to go from vague memory and was probably off.
Using home-grown XML serializers (which XMLLayout would be
considered) is discouraged since there are many edge cases that they
would not properly handle. Xerces and Xalan have provided
serializers for a long time and since JDK 1.4 there has been a
standard API for serialization as a subset of XSLT processing. If
XMLLayout was to be written today, it would look pretty much like
XSLTLayout. However, I would not recommend replacing the current
XMLLayout with a completely rewritten one at this time on the log4j
1.2 branch.
I'd propose:
1. Adding support for properties to XMLLayout, but have it be
disabled by default. Extra elements showing up in content may
disrupt existing applications that consume output from XMLLayout and
shouldn't just appear in a minor release.
2. Reviewing the holes in XMLLayout and fixing low-risk items.
Basically, items that currently produce invalid XML and can be fixed
without major surgery.
3. Adding XSLTLayout to extras. That would be an alternative if you
are encountering problems with the log4j XMLLayout, plus it would
allow output in other formats (such as Atom or RSS) just by adding an
appropriate transform in the configuration. XSLTLayout requires a
JDK 1.4, but that shouldn't be an issues with extras.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
