On Jul 1, 2005, at 6:18 PM, Simon Kitching wrote:
On Fri, 2005-07-01 at 16:13 -0700, Mark Womack wrote:
This all seems sane to me. JCL will provide a way (eventually) to
choose
between the Log4j12Logger and the future Log4j13Logger? There is
a request
to add a method of determining the log4j version which we will be
implementing for the 1.3 version. I'm sure that will help.
The JCl code tests for version by checking:
Priority.class.isAssignableFrom(Level.class)
As long as this isn't true in 1.3 everything is fine. Note that it's
also fine for the Priority class to be missing; NoClassDefFound for
this
expression also is taken as not-1.2 :-)
I'd much rather prefer to provide some other pr additional mechanism
since my gut feeling is that will will have to restore the 1.2
relationship between these classes (Level extends Priority) in order
to prevent wide-spread VerifyError when using log4j 1.3 with code
compiled against log4j 1.2.
There are a couple of scenarios:
1) log4j 1.3 is sufficiently binary compatible with log4j 1.2 that
there is no need or desire for a log4j 1.3 specific wrapper
2) log4j 1.3 is sufficiently binary compatible that there is no need,
but there is a desire for a log4j 1.3 specific wrapper to support
some feature or optimization.
3) log4j 1.3 isn't sufficiently binary compatible and needs a log4j
1.3 specific wrapper and Priority extends Level (current CVS HEAD).
4) log4j 1.3 isn't sufficiently binary compatible and needs a log4j
1.3 specific wrapper and Level extends Priority.
As long as we stay away from scenario 4, the current approach in
Log4J12Logger would be work okay. It would work with log4j 1.2 and a
hypothetical binary compatible log4j 1.3 and quickly fail with the
previous log4j 1.3 alphas. However, I'd hate to paint myself a
corner until scenario 4 with the initial log4j 1.3 release can be
totally ruled out.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
