That wasn't the intent. I'd like to bundle the thing so that
Chainsaw could be built (at least in the interim) with log4j 1.3 or
with log4j 1.2.14 plus some additional jars. The hierarchy
notification stuff wouldn't be in 1.2.14, but hopefully Chainsaw
would only be slightly degraded with it missing. After we are
comfortable that the log4j 1.2.x plus additional jars is working,
then we can break the link with log4j 1.3.
Certainly worth exploring.
I like the idea of breaking out the Receiver stuff into an
optional jar for 1.2. I can't remember if log4j1.2 had the
Plugins stuff, but even if it did, I'm sure I and others have made
some changes to that. Again, that could be ported, but we're
starting to make a significant 1.2 change, and wouldn't it make
more sense to call it....1.3? :)
log4j 1.2 did not have the org.apache.log4j.plugin package. I
wasn't suggesting reworking that component model into log4j 1.2.
I'd suspect that log4j 2.0 would use OSGi (likely Apache Felix) or
some other established component model in place of the log4j 1.3
plugin package. I guess the plugin stuff could be spun off as a
distinct package that is a dependency of the receiver package and
chainsaw.
AFAIK, Receivers are really the only plugins at the moment. It
raises the question of how we support any users that have currently
'bound' themselves to log4j1.3 . I guess since it's still marked as
Alpha, then "them's the breaks".
As a very quick hack to 1.3, I was considering testing some 1.3
LoggingEvent changes to return MDC serialization compatibility,
even if it wasn't optimal.
Thought there was an open bug for log4j 1.3 serialization
compatibility but could not find it.
I'm sure there's one, perhaps marked with Chainsaw instead of 1.3? I
think I saw one relating to MDC.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
