logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: log4j features and general readyness for use
Date Wed, 28 Jun 2006 05:04:23 GMT

On Jun 27, 2006, at 4:39 PM, Stuart Robertson wrote:

> We're considering dipping our toes into log4j 1.3 waters for a not- 
> far-off production application, and would like to get a read on the  
> developers' opinion on what areas are stable for production.  I  
> understand there are no guarantees, we won't hold you to it, etc.  
> etc., but still, you probably know which areas are in flux and  
> which are already probably how they'll look whenever 1.3 goes live.
>
> We'd actually be using it initially as a backward compatible  
> replacement for 1.2 in an application where we're experiencing the  
> dreaded deadlock issues, which it sounds like 1.3 may help resolve.
>
> Anyway, thanks for any input.
>
> Stu

Depends on what issue that you are running into.

If you are running into AsyncAppender related deadlocks, the log4j  
1.2 branch should have the recent AsyncAppender rewrite in it.  I'm  
hesitant to support a log4j 1.2.x release with the new AsyncAppender  
since there has been very little feedback on it.  The log4j 1.2  
AsyncAppender was seriously broken, but had been for a long time and  
people either weren't using it, weren't running into the problems or  
had worked around them.  Though there has been no plans for  
additional 1.2.x. releases, there is nothing preventing that decision  
being revisited.

If you are talking about deadlocks due the message parameter's  
toString() method making log4j calls itself, then I'm not sure that  
1.3 buys you anything.  I haven't seen a way to solve the problem  
that doesn't introduce a potential compatibility problem.  Though it  
wasn't documented, log4j has never (as far as I know) supported that  
scenario and so potentially breaking deployed applications to allow  
an improvement for new applications is not something that I could  
support in a 1.x release.

My personal feeling is that 1.3 is in a no-win situation.  Backwards  
compatibility was not rigidly enforced during development.  While  
there has been some success reworking the code to be compatible with  
1.2.x, I do not think that it will ever be close enough to 100%  
compatible to be a universally recommended replacement for deployed  
applications that are working fine with 1.2.x.  However, there are  
many issues (primarily involving concurrency) that will require  
breaking binary compatibility with 1.2.x to solve, but log4j 1.3.  
does not solve them.

I have outline some of my thoughts on log4j 2.0 development in the  
past and would love to spend some time brainstorming and getting an  
outline and some sample code together.  However, I've been resource  
constrained due to revenue generating projects.  However, I think it  
is close to time to opening up a log4j 2.0 branch and getting some  
development started.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message