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: 1.3 - A Line in the Sand
Date Tue, 03 Apr 2007 17:51:24 GMT

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 general@logging 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message