On Sep 15, 2006, at 10:24 PM, Scott Heaberlin wrote:
I probably should post this to the log4j-dev list, but I figured there
might be other log4j users out there wondering this same thing.
What is the status of log4j 1.3? I was wondering why I felt such
deja-vu writing this, then I recalled an old e-mail... dated mid 2004.
http://marc.theaimsgroup.com/?l=log4j-dev&m=108138515925098&w=2
Is there something in particular holding up a release? No offense,
but I seem to recall during the 1.2.9 vote (I think, could be off
here) hearing that there were no more 1.2 branch releases. In fact,
the website (http://logging.apache.org/log4j/docs/plan.html) states
this. Yet right now, 1.2.14 is up for vote. I don't have anything
against the 1.2 branch; its output has saved me countless hours of
troubleshooting over the years. It seems like every few months I have
a business need in an application to support centralized logging...
and oh I wish I could use receivers... but I can't.
I'm one of those developers who works in a shop that frowns on beta /
pre-"release" libraries so I'm unable to use log4j 1.3 yet. I've been
hearing & reading about senders/receivers, domains, joran
configurator, and other nifty features - but I still can't use them.
I have the utmost respect for the log4j dev team - like I said I've
accomplished a lot with the 1.2 branch over the last few years. But I
gotta ask... are we really going to see 1.3?
Respectfully yours,
-Scott
I expect to prepare a log4j 1.3 alpha 9 release shortly. log4j
1.2.14 was a priority since 1.2 is in production use and the locking
problems with AsyncAppender had apparently been substantially reduced
or hopefully eliminated with the rewrite of AsyncAppender in the
trunk and backporting it to the v1_2-branch.
As part of the log4j 1.2.14 release, I synchronized the documentation
between the 1.2 branch and the trunk (aka 1.3). While reviewing the
docs, it was clear that both the roadmap in the log4j 1.2 branch and
trunk were seriously dated. I attempted to write a "roadmap" that
while it is pretty non-committal, but gives at least a more realistic
appraisal of the state of things. Here is a quote from the plan.html
in the 1.2.14 release candidate:
The Roadmap
This page documents that roadmap and gives you an idea of what to
expect from future versions and timeframes for release.
Our users keep inventing better ways and adding new requirements.
The downside is that our todo list keeps growing. The upside is
that there is plenty of work to go around. If you are interested in
participating, send an email on the log4j-dev@ mailing list stating
your interest. You'll be promptly enrolled. We're always looking
for help! Don't be put off if in the "Volunteer" column already has
a person listed. Programming is fun, especially if it is done in a
team.
Release 1.2.15
Expected timeframe: As needed
log4j 1.2.14 was released in September 2006. log4j 1.2 is
continuing to be maintained in response to reported problems*, but
no active development is anticipated in the near future.
Backporting the org.apache.log4j.rolling package from log4j 1.3
might be desirable since usage problems with the original
org.apache.log4j.RollingFileAppender and
org.apache.log4j.DailyRollingFileAppender are commonly reported.
Release 1.3
Expected timeframe: indeterminate
Compatibility with earlier releases (as implied by a minor verion
number change) was not enforced during the development process and
much of the recent effort has been to restore compatibility.
However, it does not seem likely that log4j 1.3 will ever been
sufficiently compatible with log4j 1.2 to recommend it as a general
replacement for log4j 1.2. Additional alpha releases are expected,
however it is possible that the development focus may shift to
log4j 2.0.
Release 2.0
Expected timeframe: indeterminate
log4j 2.0 is still conceptual but would be designed for Java 5 and
later, would use be designed for fine-grain concurrency to maximize
performance on multi-processor systems, would minimize exposure of
implementation details and adhere to current Java coding practices.
The design of log4j 2.0 may attempt to support javax.util.logging
by allowing, for example, a log4j 2.0 Appender to serve as a
javax.util.logging.Handler. log4j 2.0 would likely be modularized,
possibly using OSGi and would include a facade that emulates the
log4j 1.3 API but would not be compatible with user written
appenders and other components.
* - "problems" or "bugs" should have appeared at this spot, but was
inadvertently omitted.
I would not stand in the way of any one who wants to push log4j 1.3
to completion. However as a volunteer, I do have control over the
tasks that I personally take on. At the moment, the most appealing
course of action for my personal involvement is to get another 1.3
alpha out, a log4cxx build out and then turn my focus to log4j 2.0.
I think the timeline to an production quality log4j 2.0 is shorter
and more beneficial to the community than throwing more effort on
log4j 1.3.
My issues with log4j 1.3 advancing to beta or release:
Remaining compatibility issues with log4j 1.2:
While binary compatibility issues have been substantially reduced,
there are still some remaining, for example, extended
DOMConfigurator's would not be expected to work. While that may not
have been an intended extension point, it had not been prohibited by
making the class or methods final. In addition, there are
intentional behavioral compatibility issues that would cause an
application that works fine with log4j 1.2 to fail to work with log4j
1.3. The most prominent is the enforcement that appenders that
previously worked without a call to activateAppender() now require
calls to activateAppender(). Those types of compatibility issues
seem unacceptable for what is labeled a minor release of a production
product.
One quick solution to the compatibility issue would be to change the
package name so that promise is that the implementation is mostly
source code compatible instead of highly compatible. However, I
believe that NLOG4J (http://www.slf4j.org/nlog4j/) already fits that
description as my understanding is that it was a log4j 1.3 fork with
essentially only the package names changed.
New features that partially replicate JDK classes:
I believe the Scheduler would fit into this as it appears to
replicate a class in java.util.concurrent package what was
incorporated in JDK 1.5 and I believe was available in JDK 1.4.
Scheduler has been failing its unit tests on Gump for quite some
time, so either it or the tests have some problems that would need to
be addressed before a production quality release.
org.apache.log4j.helpers.MessageFormatter does message formatting
using a syntax similar to but not compatible with
java.text.MessageFormat which has been available in since early
JDK's. The rationale for the independent implementation and variant
syntax was performance, however benchmarking the MessageFormat
implementation in the formatter sandbox project (which use an
optimized implementation for simple patterns and delegates to the JDK
class for more complex patterns) shows that a MessageFormat
compatible syntax can offer equivalent performance.
Review of new features:
Quite a few features were added without much or any previous
discussion. Even it there had been discussion at the time, it would
be prudent to carefully review all API additions before committing to
supporting them.
Concurrency:
log4j 1.3 does not make significant changes in the coarse grain
concurrency (basically only one message can be dispatched and
formatted at a time) from earlier log4j's and it is unlikely that it
could do so without introducing compatibility issues. Also keeps
antiquated practices of synchronizing access to StringBuffers and the
like instead of creating new instances. While it offered performance
benefits in earlier JDK's, the performance benefit has been reduced
or eliminated while still retaining the synchronization downside.
Coding practices:
Lack of use of private and final qualifiers where they would have
been appropriate makes it difficult to change implementations.
In light of these and other problems, my opinion is the best path
forward is continue to maintain log4j 1.2 as the stable offering and
final stable offering for JDK 1.4 and earlier. Offer log4j 1.3 as an
experimental product but don't imply that you can mix and match log4j
1.2 and log4j 1.3 on the classpath or swap them out without risk.
Start sandbox architectural experiments for log4j 2.0 (actually
strictxml and formatter might already be considered to architectural
experiments for log4j 2.0) and target JDK 1.5 and later.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
