On Wed, 2005-04-27 at 01:53 -0500, Curt Arnold wrote:
> I sorry I really can't follow this thread. There seem to be a couple
> possible issues that are trying to be raised, but I can't be sure.
>
> 1. You don't like using < or > in an XML configuration file to
> specify a '<' or '>' character.
I was unaware of the configurable xml output. I was using plain text
output from a text properties file.
My complaint was that the use of an xml properties file, to format
plain text output as xml (I see what you mean :-) meant me writing
invalid XML in the properties file... markup in the attribute is a no-
no.
>
> Using a PatternLayout to fabricate XML elements is not robust since it
> will not properly escape messages that contain markup characters.
If I did that I'd have myself to blame :-) but yes, agreed.
> If
> you know that your messages never contain markup characters and are
> willing to accept the consequences, it should work but you would need
> to escape the markup in the XML configuration file like:
>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern"
> value="<e><t><%d{yyyy-MMM-dd
> HH:mm}</t><lvl>%-5p</lv><m>%m</m></
> e>%n"/>
> </layout>
Which is a.... (insert impolite comments :-)
>
> Obviously, your configuration would be prettier if the configuration
> file processor magically knew when you wanted < to be a literal and
> when you wanted it to be part of an tag.
And for which a solution would be to take configuration content
into elements, rather than leave them in attribute values.
> However, adding complexity
> and context-specific behavior to make the document prettier goes
> against the XML ethos. < marks the start of a tag, < is the '<'
> character and we need to stick with that.
Disable output escaping is a perma-thread on the xslt list as people
ask how to do just that.
>
> 2. You'd like to be able to control the namespace, element names, etc
> in an XML log
Yes please.
>
> If you are browsing the generated logs using a browser, you could use
> an XSLT style declaration and many browsers would apply the stylesheet
> and display the transformed log.
I'd rather parse it using XSLT and produce appropriate output as
a more general process. Seems more flexible to me?
>
> If you can't apply XSLT processing to the currently generated XML
> format, it could be possible to enhance the XMLLayout (or provide an
> alternative layout) to provide some facility for controlling the
> generated output. I have some ideas but I don't want to go down that
> path if that isn't your concern.
I'm treading (very carefully) into java I've not trod in before,
but I'm moving that way; see my earlier thread.
>
> 3. The existing XMLLayout fails for particular message content and you
> are trying to find a work-around
I only found out about it last night, so I have some catching up to do.
Clearly it is not as flexible today as the text output.
>
> Please clarify what your issues. Using PatternLayout to fabricate XML
> messages will never be robust so do not expect us to make any
> improvements to make it better at something that it will eventually
> fail at.
Fair comment.
> If there flaws in XMLLayout or unsupported use-cases please
> describe them and we can consider enhancements or alternatives to
> XMLLayout.
Basic requirement.
To enable the selection of any existing formatting option and
add it to the XML output, using my own specified elements or
attributes.
E.g.
%L # Linenumber
Somewhere I'd like to be able to say
I want the linenumber, I'd like it output as
<ln>64</ln>
or
%F, filename
I want
<fname ln="{%L}">myfile.java</fname>
That level of flexibility, which is an xml view
of what I can do with the text properties file.
Am I making sense?
regards DaveP
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
