On Apr 2, 2007, at 7:07 PM, Paul Smith wrote:
At some point we can no longer ignore the decision about where 1.3
should go.
I am beginning to think that we should scale back 1.3 to be less of
the planned revolution and more of a substantial-update-but-
completely-backward compatible (to a point).
We can then step back and think way beyond 1.3 and come up with a
new vision for what we think is important in enterprise logging.
Firstly, what do people think of this idea?
log4j 1.3 in my opinion is stuck in a hopeless position. It is too
incompatible with log4j 1.2.x to ever be recommended as a drop-in
replacement for log4j 1.2 in a production environment. However, if
you changed log4j 1.3 to be drop-in compatible with log4j 1.2, then
you would break any apps that had depended on its 1.3-ness.
Secondly, what do people think is left to do before preparing for
a fully supported 1.3 release ?
There are still API incompatibilities (http://people.apache.org/
~carnold/compatibility.html), particularly any user extensions of
DOMConfigurator (bug 39024) would not work with log4j 1.3.
LoggingEvent is not serialization compatible (bug 35159).
LoggingEvent.sequenceNumber can't achieve what it thought it could
achieve and should be removed (bug 36555, maybe others). The Gump
runs have been failing for over a year on the scheduler code behind
the reworked configureAndWatch methods. Mark Womack threw a quite a
bit of time on that and could not get it diagnosed. And if you
fixed all that, you would still break apps that didn't explicitly
call activateOptions(), it would not address the fundamental
concurrency problems and would still target early JDK's.
Third, who in the dev community (not just committers) is prepared
to provide some effort in this regard.
Elias Ross appeared to be motivated to push log4j 1.3 forward and
while I did not think it was where I thought my time was best spent
(and I've spent a huge amount of time killing off incompatibilities),
I was willing to let him prove me wrong and the PMC granted him
commit privileges. Unfortunately, he did a bug fix spurt and then
disappeared.
On Apr 3, 2007, at 12:10 AM, Jacob Kjome wrote:
I think it's been said before that 1.3 may be more of a dead end
than anything else. Some interesting things went into it, but the
fact that it became so incompatible with Log4j-1.2.xx is a real
problem. Is it worth a release or do we just leave it as-is,
forever alpha, and move on to 2.0?
I think forever alpha and move on to 2.0.
>We can then step back and think way beyond 1.3 and come up with a new
>vision for what we think is important in enterprise logging.
>
>Firstly, what do people think of this idea?
>
As long as we're considering things that have been ignored for a
while, what is our official take on Logback? It's basically a
realization of what Log4j-1.3 was supposed to be, no?
I've been hesitant to deeply examine logback as its code is LGPL'd
and would want to avoid leakage of logback code into log4j. We have
a bit of a marketing disadvantage here as Ceki has been very vocal on
the mailing lists encouraging people to migrate to logback and saying
that log4j development is dead (I'd agree that it hasn't been healthy
recently, but we've never decided that it is dead). I'm also a bit
of a lightning rod for Ceki and think any evaluation of logback would
be better coming from someone else.
Do we really have plans to best it as Log4j-2.0? I'm not saying we
don't. I'm just asking the question.
logback is always going to be a better logback than log4j 2.0 and
likely a better log4j 1.3 than log4j 2.0. However, I think that the
design goals and approaches envisioned for log4j 2.0 will result in
something valuable to the community.
And what are we going to do about SLF4J? It's gained significant
acceptance and we've punted on how we are going to approach it;
implement it directly, write a wrapper for it (actually, this has
already been done by the SLF4J team), or ignore it altogether. So
far, we've chosen the latter as the path of least resistance.
From a packaging and maintenance perspective, it has always been
preferable that SLF4J be a wrapper over log4j. There were never any
benchmarks provided to quantify the supposed performance benefit of a
direct implementation. If I remember correctly, supporting SLF4J
directly introduced a breaking API change when code was recompiled.
I think the current state is the best for the community. log4j 1.2
users who want to use SLF4J can do so without forcing them to update
their log4j 1.2 version and log4j does not have a dependency on SLF4J.
>Secondly, what do people think is left to do before preparing for a
>fully supported 1.3 release ?
>
Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
much larger than 1.2 because of, among other things, Joran. Joran
in 1.3 was Ceki's brainchild and continued development of it has
long since moved to Logback. I'd be more comfortable letting
Logback developers maintain the official version and use it instead
of maintaining it ourselves. I can't recall where I read it, but I
believe it was stated that Joran could be used in other projects,
separate from Logback. Of course, then why not just use Logback?
Unless people are truly prepared to put in the time to figure out
what the future of Log4j should be (and implement it), I'm afraid
that Log4j-1.2.xx is the end of the line, though I'm completely
open to being proved wrong.
Joran is not the only configuration processor in existence, there are
likely several in ASF alone (http://ws.apache.org/synapse/
Synapse_Configuration_Language.html for example). I'd see log4j 2.0
primarily configured by JMX and expose a configuration API that could
be driven by a log4j 1.2 compatible property and dom configurators
and something like the strictxml configurator.
On Apr 3, 2007, at 2:09 AM, Paul Smith wrote:
I think it's been said before that 1.3 may be more of a dead end
than anything else. Some interesting things went into it, but the
fact that it became so incompatible with Log4j-1.2.xx is a real
problem. Is it worth a release or do we just leave it as-is,
forever alpha, and move on to 2.0?
From a Chainsaw point of view a lot of work on creating good
Appender->Receiver stuff was done, and as I setup a decent
environment for our QA and Ops team to use Chainsaw through a
firewall (port forwarding) while our app is using log4j 1.2.14, I'm
beginning to see a dilemma. serialized LoggingEvents from 1.2 just
don't contain lots of info coming out the other end. I then asked
myself the question "Should we upgrade our app to use log4j 1.3",
and I honestly couldn't say what the quality was, hence the line-in-
the-sand email.
I'd love to hear (in a different thread) what would need to be back-
ported to log4j 1.2.x to move Chainsaw back over it.
As long as we're considering things that have been ignored for a
while, what is our official take on Logback? It's basically a
realization of what Log4j-1.3 was supposed to be, no? Do we
really have plans to best it as Log4j-2.0? I'm not saying we
don't. I'm just asking the question. And what are we going to do
about SLF4J? It's gained significant acceptance and we've punted
on how we are going to approach it; implement it directly, write a
wrapper for it (actually, this has already been done by the SLF4J
team), or ignore it altogether. So far, we've chosen the latter
as the path of least resistance.
My somewhat superficial scan over logback shows a lot of promise
from an end user point of view. I would certainly be interested in
exploring that as an option. This is where licenses, politics and
marketing all come to a head which are never fun.
* Is bringing logback into Apache something the logback community
would even remotely consider? Ceki, I know you're watching, do you
think that it might obtain wider exposure by coming under the
logging.apache.org banner? Is that something that you've ever
thought of? I totally respect the community logback has already
established.
* Would the Apache dev community even consider looking at that sort
of proposal?
I think offering logback with a double license (LGPL and ASL) would
be beneficial. Ceki spun off the SLF4J effort since he thought he
would be more effective outside of the ASF and the overhead of
community development and governance. I haven't seen any indication
that that has changed. Also, it would have to come through the
incubator and that isn't fun. I believe the ASF board is determined
that code that isn't developed in accordance with open, public
discussion and conflict resolution should not be in the ASF.
Apache log4j has a decent 'brand' behind it, and many people are
familiar with it and support it, but we've become stagnant, and
perhaps people are moving on. The logback project, if 'absorbed'
as a new log4j version could well gain bigger traction quickly
purely because of that brand and revitalize logging.apache.org as a
broader community (I'm thinking non-java languages here). What
we want is a healthy dev community, and right now I'm not sure we
(log4j) have one. Curt's been the only one doing anything recently.
I'm definitely supportive of efforts with other languages (but it
would also need to come with motivated developers). There is an open
bug request on logging for Javascript (bug 36961). I don't think
that the health of log4j development or bringing logback into LS
would make or break a log4js or a log4 ruby et al. If someone is
interested in building a community for an effort in a particular
language, start a thread on [EMAIL PROTECTED] and we can look at
starting a sandbox project.
I'd be keen to consider starting Chainsaw v3 from scratch along
side any post-log4j1.3-type operation and build in exceptional
support for enterprise log management, but I'm only one person, and
I know many of us are incredibly busy, but we were so active there
for a while I think of the potential of what we could achieve! :)
From a Java point of view I think many of the Java 1.4+ network
library, and java.util.concurrent stuff could be well used in a new
logging package.
Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is
much larger than 1.2 because of, among other things, Joran. Joran
in 1.3 was Ceki's brainchild and continued development of it has
long since moved to Logback. I'd be more comfortable letting
Logback developers maintain the official version and use it
instead of maintaining it ourselves. I can't recall where I read
it, but I believe it was stated that Joran could be used in other
projects, separate from Logback. Of course, then why not just use
Logback? Unless people are truly prepared to put in the time to
figure out what the future of Log4j should be (and implement it),
I'm afraid that Log4j-1.2.xx is the end of the line, though I'm
completely open to being proved wrong.
What you say certainly seems possible. If we're not careful, the
log4j project could dwindle into nothing (not that that's a
problem, just sad).
I expressed some of the same sentiments in the last board report.
Unfortunately, the minutes haven't been published yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
