On Wed, 27 Apr 2005 13:03:02 -0500
Curt Arnold <[EMAIL PROTECTED]> wrote:
<snip>
> There is a decent likelihood for XMLLayout to change
>before final release of log4j 1.3, so it may be better to
>avoid subclassing it since it really doesn't appear to be
>designed for extension and not that hard to duplicate. I
>think it should have been marked final, but then I think
>that about a lot of things.
Ok, now I'm worried.
I use a subclass of XMLLayout (see below) which was based on the log4j1.2.9
implementation. I've seen that there have been big changes to the
implementation of XMLLayout since 1.2.9 but thought that all the changes
were backwards compatible.
If this is not the case then I have some work to do before I can adopt 1.3
:-(
If the actual xml output or the log4j.dtd has changed/will change in an
incompatible way it will prevent going to 1.3 as I have 3rd party apps which
have been developed to parse the output from my custom layout which
validates against the current log4j.dtd.
>
>>
>> (And the next request will be...
>> Can I ask some module who knows, to output
>> <log4j:log>
>> before my application starts writing and
>>
>> </log4j:log>
>> just before finishing :-)
>>
>
>A log file can be appended to by several invocations of
>an application each of which appends to the running log.
> If each invocation wrote <log4j:log> and </log4j:log> at
>its start up and termination, you would still have the
>problem of multiple document elements.
>
>A possible solution is to use a
>o.a.l.rolling.RollingFileAppender with a RollingPolicy
>that instead of just renaming the file on a roll, it
>would add the outer document element.
>
My requirement was to be able to publish 'fatal' log messages onto a JMS
queue for consumption by a third party 'Error reporting system'. As this
system is non-java, I decided to implement this by writing a custom JMS
appender which uses a javax.jms.TextMessage rather than serializing the log
event. I then wrote the following XMLLayout subclass to render each message
as a complete xml document rather than a fragment:
public class XMLDocumentLayout extends XMLLayout
{
public String getHeader()
{
return "<?xml version=\"1.0\" ?>\n"
+ "<!DOCTYPE log4j:eventSet SYSTEM \"log4j.dtd\">\n"
+ "<log4j:eventSet version=\"1.2\"
xmlns:log4j=\"http://jakarta.apache.org/log4j/\";>";
}
public String getFooter()
{
return "</log4j:eventSet>";
}
}
This allows each message to be checked to be well-formed and validated
against the log4j.dtd at the remote end. It is then parsed and actioned by
the fault reporting system.
I thought the log4j.dtd was quite stable, have I made a booboo going down
this route?
Regards
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
