Re: Log4j 1.3 Woes

[Jess Holle]

Curt Arnold wrote: 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. I'll have to review those threads... 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. That all makes good sense.  I do believe that some statement to this effect on the log4j site, a request for help in identifying and addressing such issues, some determination as to the validity of the recipes for preparing code for 1.3, and near-term efforts to resolve issues and/or the recipes so that good advice can be given are all necessary as soon as possible.  In particular, while not using Category or Priority directly sound well and good it seems quite uncertain that that will actually buy anyone anything substantive in the end. 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. Understood. 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. That seems *way* too far off given that 1.3's release timeframe itself is still quite hazy.  If this cannot be resolved in any definitive near term then I guess it is time to start my converting to JULI now... I understand and accept that this will break some applications, but 1.3 seems like a fine time and place to do this -- assuming 1.3 releases some time in the next 6 months. 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. Understood, but a timeframe for addressing the issue -- without unnecessarily introducing other compatibility issues -- is still necessary. 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. I think we must in 1.3. On the other hand, I've not seen the deadlock in my application yet, so it may never hit it.  The specter of such an issue cannot be accepted for long, however. -- Jess Holle