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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
