"Compelling Reasons to adopt log4j2"

[Paul Smith <ps...@aconex.com>]

I got stuck, and all I can think of are these.  Other people may want  
to look at this and think about what might compel them to switch to  
log4j2 (when we get there.. :) )

Compelling Reasons for a log4j2 adoption

* Ease of migration/Drop in replacement for log4j 1.2 - If we do not  
meet this fundamental goal, I seriously doubt we'll ever gain  
traction.  We should be free from the log4j1.2 design, but we should  
begin early to ensure that the core design can be easily shimmed with  
a log4j2-1.2compatibility.jar or equivalent.

* Finer grained synchronization - log4j1.2 has a weakness in it's  
synchronization mechanism that can cause problems in high load  
situations.   In it's earlier years this was never a problem, but  
more and more people hit these bottlenecks.

* Simplicity of management - 1.2 has a nice and easy .properties  
and .xml configuration mechanism but lacks finer grained runtime  
management controls. The jmx support in 1.2 is rather weak.

* Advanced Context logging - go beyond MDC and NDC to domains/markers  
and other concepts.  Provide advanced tools to easily correlate  
logging events together for analysis.

* Locale-based logging - not everyone speaks English, or a single  
language.  Applications written for other countries may wish to  
deploy with bundles for logging messages.  The var-args support in  
Java 5 makes this one easy-peasy.  It also can limit the cost of  
logging String concatenation and remove the ugly code "if 
(LOG.isDebugEnabled())".  If the LOG.debug(...) statement can take  
var-args, then there is no overhead of string construction until the  
actual point you know you have to append something.

* Small core module size - not one big uber jar (people are funny  
about large jars) - a somewhat weak argument, but you'd be surprised...

Paul Smith
Core Engineering Manager

Aconex
The easy way to save time and money on your project

696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200  Fax: +61 3 9240 0299
Email: psmith@aconex.com  www.aconex.com

This email and any attachments are intended solely for the addressee.  
The contents may be privileged, confidential and/or subject to  
copyright or other applicable law. No confidentiality or privilege is  
lost by an erroneous transmission. If you have received this e-mail  
in error, please let us know by reply e-mail and delete or destroy  
this mail and all copies. If you are not the intended recipient of  
this message you must not disseminate, copy or take any action in  
reliance on it. The sender takes no responsibility for the effect of  
this message upon the recipient's computer system.

Re: "Compelling Reasons to adopt log4j2"

[Curt Arnold <ca...@apache.org>]

On Apr 17, 2007, at 1:16 AM, Paul Smith wrote:

> I got stuck, and all I can think of are these.  Other people may  
> want to look at this and think about what might compel them to  
> switch to log4j2 (when we get there.. :) )
>
> Compelling Reasons for a log4j2 adoption
>
> * Ease of migration/Drop in replacement for log4j 1.2 - If we do  
> not meet this fundamental goal, I seriously doubt we'll ever gain  
> traction.  We should be free from the log4j1.2 design, but we  
> should begin early to ensure that the core design can be easily  
> shimmed with a log4j2-1.2compatibility.jar or equivalent.

Not drop-in in the sense that you should feel free to take your  
production app and replace log4j 1.2 with log4j 2.0+shim without  
testing, but reasonable expectation that most mainstream uses can  
work with the shim.

>
> * Finer grained synchronization - log4j1.2 has a weakness in it's  
> synchronization mechanism that can cause problems in high load  
> situations.   In it's earlier years this was never a problem, but  
> more and more people hit these bottlenecks.

Yep

>
> * Simplicity of management - 1.2 has a nice and easy .properties  
> and .xml configuration mechanism but lacks finer grained runtime  
> management controls. The jmx support in 1.2 is rather weak.
>

Plus Spring and other IoC management.  You should be able to  
configure log4j with the same config system that the rest of your app  
uses, at least in certain configs (aka not log4j 1.2 shim).

> * Advanced Context logging - go beyond MDC and NDC to domains/ 
> markers and other concepts.  Provide advanced tools to easily  
> correlate logging events together for analysis.

Good area for experimentation, particularly when we look at the  
native log4j 2.0 logging API.  Don't think it affects the back-end  
design significantly.

>
> * Locale-based logging - not everyone speaks English, or a single  
> language.  Applications written for other countries may wish to  
> deploy with bundles for logging messages.  The var-args support in  
> Java 5 makes this one easy-peasy.  It also can limit the cost of  
> logging String concatenation and remove the ugly code "if 
> (LOG.isDebugEnabled())".  If the LOG.debug(...) statement can take  
> var-args, then there is no overhead of string construction until  
> the actual point you know you have to append something.
>

Localization can be handed either at the API end by resource bundles  
and parameters or at the appender end by translation (I discussed  
that approach a couple of years ago in the Enterprise Logging threads  
here and in commons-logging).  I think likely we should support  
both.  Since the java.util.logging supports resource bundle logging,  
we'd likely be in a good position if we design for interoperability  
with java.util.logging.  A translating layout could implemented in  
log4j 1.2.x, so I don't think it adds any design constraints.

If the "ugly code" concern is strictly formatting and not  
localization, then the formatter sandbox project can address that now  
as a log4j 1.2 companion.


> * Small core module size - not one big uber jar (people are funny  
> about large jars) - a somewhat weak argument, but you'd be  
> surprised...
>


My favorites are:

java.util.logging interoperability.  Discussed earlier.

Designed for Java 5 and later

Better error handling and diagnostics.




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