There were two fairly long threads this summer on the topics raised
in this thread (http://marc.theaimsgroup.com/?l=log4j-
dev&m=111901190409097&w=2 and http://marc.theaimsgroup.com/?
t=112094138900003&r=1&w=2). I haven't seen any new issues here, just
a reiteration that we are not in a happy place at the moment.
Basically, 1.2 and 1.3 are not binary (aka classfile) or
serialization compatible at the moment. It is definitely possible
you will get a class loader exception if you run code compiled
against 1.2 with a log4j 1.3 jar. The breaking of binary
compatibility occurred before most of the current developers became
involved and we are trying to restore binary compatibility, but
obviously would have liked to have made more progress. One of the
reasons that we are still calling 1.3 an alpha is we want to change
that which will likely break some code that was compiled against
earlier log4j 1.3 alphas.
Resolving the "deadlock issue" (bug 24259 and 33855) in my opinion
will require breaking the existing threading contract which will
likely cause applications that depend on the current behavior to
break. As such, I do not think that there is a possible fix except
in the forthcoming 2.0 branch (which would not be constrained to
binary compatibility) and then it may require a bit of
experimentation to find the right tack. My personal preference would
be to rework a lot of the formatting and dispatching code to be more
verifiably thread safe and use finer grain locking than what we
currently have, but as a project we can't make those types of
decisions until we see some code. The issue is not a regression,
just a downside of the threading strategy that has been in log4j for
a long time.
It may be possible to improve the locking behavior for a particular
application in a branch of either 1.2 or 1.3 (at the potential
expense of breaking or changing the performance of other apps), but I
don't think we can offer a general purpose improvement in the 1.x
releases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
