On Apr 27, 2005, at 3:52 PM, Andy McBride wrote:
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.
Thanks for the info and sorry for the scare. I would not expect any changes that should adversely affect API or XML compatibility and would raise any potential issues before proceeding.
In this case, David Pawson's was undertaking an custom layout that would reuse very little of XMLLayout and it would be prudent for him not to extend XMLLayout if it is a total or near total replacement. For example, if the enhancements to XMLLayout allowed specifying whether CDATASections were used, his extension of XMLLayout would inherit that configuration parameter but since he would be totally replacing XMLLayout.format, it would have no effect.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
