Re: Design and evoluton of log4j (Was: AppenderSkeleton.isActive, etc)

[Jacob Kjome <ho...@visi.com>]

Ok, guys, don't you think all this has gotten a bit out of hand?

Ceki, apparently you committed code that cause incompatibilities with those 
implementing appenders against Log4j-1.2.   There was no discussion of this 
beforehand and no one, but maybe Curt (because of the phone call), had a 
clue as to why this was done or what was being planned in the future.  For 
that matter, we still don't really know what's being planned other than a 
basic commit comment and a statement that you got hung up on stuff but are 
working on it.  I'm sure, functionally, it is something good (as 
usual).  However, I take exception with both the lack of information and 
the tone of your emails.  I was actually a bit taken aback because you are 
usually calm, cool, and collected.  Hopefully it was an aberration!

Curt, I understand your wanting to keep compatibility.  I tend to agree 
that if we can do it at the same time as adding new features, then we 
should strive for that.  We broke compatibility with RepositorySelector's, 
but because there are few (if any besides the log4j-sandbox, which are now 
removed) outside implementations and it added real value to Log4j-1.3, it 
made sense.  I'm not sure it does make sense here.  I'm not saying I have a 
technical reason, I'm just saying I have a lack of information so I can't 
know if it does or not?  Likewise, you couldn't have known either and, 
although I fault Ceki with a lack of information here, I believe you should 
have waited to hear directly from him for his reasoning before doing any 
reversion of code that he committed.  No other committer could have given 
an authoritative opinion on whether to revert this change since only Ceki 
knew why the change was done.  While Gump is useful, keeping it constantly 
happy is not as important intra-project communication.  Don't let this keep 
you from continuing to be the active contributor you have been.  You've 
been very helpful to this project and I hope that continues!

So, Ceki, can we expect some details on why the new changes in appender 
functionality make it impossible to keep backward compatibility?  And if it 
isn't impossible (since Curt's modification was really not all that 
involved), why do you treat backward compatibility as such an unimportant 
issue?   If it is possible to provide a smooth migration between 1.2.x and 
1.3 with not too much effort, I think we should do that.  Certain methods 
can be deprecated in 1.3 and removed in a later version.  Then again, if 
this is simply a fundamental change in design and it will provide 
buko-benefit to users, then so be it, but explain yourself.  Don't commit 
something that you know will set people's hair on fire, be silent about it 
causing people to scramble, and then write an abrasive "People" 
speech.  You had to expect what happened, and if you didn't you were being 
extremely shortsighted.

That's all I have to say.  I'm not trying to extend the discussion or lay 
blame.  We're all fallible.  Let's admit mistakes and take action to avoid 
them in the future rather than let it devolve to this.  We've got a good 
group and a good community.  Let's strive to keep it that way!


Jake 


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

Re: Design and evoluton of log4j (Was: AppenderSkeleton.isActive, etc)

[Mark Womack <mw...@apache.org>]

OK, every take a deep breath and count to ten.  Please keep one thing in 
mind.  Everyone is acting in what they feel are the best interests of the 
project.  Ceki is making changes he thinks are important.  Curt is 
registering concern and reverting changes to keep things in sync.  Everyone 
is voicing an opinion.  We are all acting in a vacuum of information, in my 
opinion.

I have to agree with Jake.  With all of the other interface changes I can 
think of (RepositorySelector, Configurator), there was some sizable 
discussion around what the changes were, what the changes would mean, whom 
they were most likely to affect, alternatives, and an assessment of benefit. 
If there was something like that for these recent appender changes, I missed 
it.

I'm not saying that these changes don't have benefit, but they were made in 
a vacuum, and the rest of us have been trying to figure out what is going 
on.  I think that the process is working correctly, though the words are 
getting a bit harsh on both sides.  Gump failures indicated that the changes 
were affecting projects, that is what it is supposed to be doing.  Doesn't 
mean we have to revert the changes immediately; I believe that we have 
already stated that we will not be jumping all over ourselves to make sure 
Gump is happy all of the time.  However, Curt (or anyone else, committer or 
not) is well within rights to bring up the issue as a red flag.

I have said before that changes to the Appender interface are a very big 
deal.  Almost no one has written their own RepositorySelector or 
Configurator, but almost everyone has written their own appender.  It was 
one of the first things I did when I installed and learned about log4j. 
That is the beauty of the log4j design, that I can write such a customized 
piece of code and still have it fit into the framework.  With folks like 
Mark Masterson speaking up (author of SNMPTrapAppender), I think it is an 
indication of the level of reaction we can expect from the community in 
making a change in this area.

Doesn't mean that a change should not be be made.  Means it should be 
discussed.  We need to understand what the changes are supposed to be 
solving.  What will be the affects of the change.  When I hear terms like 
"life cycle management", I start to think there is more going on.  We might 
decide, as a community, that we don't want to make those changes, that we 
would rather live with the issues and maintain the api compatibility.  That 
is the process.  Let's follow it.  If it was a change to an area that 
doesn't get much focus or something inside the internal guts of log4j, we 
would not be having such a lengthy and somewhat heated discussion.

Ceki, I think we need to understand exactly what you were trying to solve 
with the changes.  You might have already said this and I just missed the 
thread.  The rest of us need to understand this.

-Mark 



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

Re: Design and evoluton of log4j (Was: AppenderSkeleton.isActive, etc)

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

On Feb 26, 2005, at 5:25 PM, Jacob Kjome wrote:

> Curt, I understand your wanting to keep compatibility.  I tend to  
> agree that if we can do it at the same time as adding new features,  
> then we should strive for that.  We broke compatibility with  
> RepositorySelector's, but because there are few (if any besides the  
> log4j-sandbox, which are now removed) outside implementations and it  
> added real value to Log4j-1.3, it made sense.

I agreed with that decision.  It did break the Gump build of Jetty  
since they had implemented their own repository selector.  There seemed  
to be no reasonably simple way to maintain backward compatibility and  
it would have been fairly simple for them to modify their code to work  
with both log4j 1.2 and 1.3.  However, since that project was dormant  
(after being consumed into an Apache project, I believe), their Gump  
descriptor was modified to point to log4j 1.2.

I did a quick scan of Gump descriptors and the projects are configured  
to build against log4j 1.2:

excaliber-logging :  switched 1/15/2005 due to API change in  
DOMConfigurator.doConfigure.

eyebrowse: switched 10/11/2004, no mention in their dev mailing list

jakarta-turbine-fulcrum: switched 2/11/2005, Must have same logger as  
excaliber-logger

jakarta-velocity: switched 12/01/2004, appears to be due to the change  
of o.a.l.RollingFileAppender to o.a.l.rolling.RollingFileAppender
http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=velocity- 
dev@jakarta.apache.org&msgNo=11427

james-server: log4j-1.2 dependency added 10/17/2004.  No mention of the  
motivation for choosing to build against 1.2 instead of CVS HEAD.

None of these projects appear to be dormant.  They represent about 5%  
of the Gump projects which I think is a surprisingly high loss for a  
dot release among our friends.  If 5% of closed-source projects that  
use log4j have similar issues, we are going a pretty constant stream of  
frustrated corporate developers once 1.3 approaches release.

I don't know if this is reliable, but  
http://brutus.apache.org/gump/public/gump_stats/module_dependees.html  
indicates that more Gump projects depend on logging-log4j-12 (450) than  
logging-log4j (384).  I guess due primarily to velocity and excalibur's  
dependence on log4j 1.2.

Hopefully as we move towards 1.3, we can bring some of these back into  
the fold where they work with both 1.2.x and 1.3.  However, I think we  
should avoid making major projects like Velocity choose between 1.2 and  
1.3 if we can help it.


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