You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2005/02/26 18:51:42 UTC
Re: Design and evoluton of log4j (Was:
AppenderSkeleton.isActive, etc)
Mark,
Over the years, I have always strived to listen to all the opinions voiced.
I also try to accommodate opinions diverging from mine and when it boils
down to a matter of taste, I tend to privilege the opinions of others over
my own. Certainly, there are examples that go both ways.
From a more general perspective, we have to ask ourselves how we want to
see the log4j code evolve. One approach, apparently advocated Curt,
consists of religiously preserving 100% and absolute backward
compatibility. In my opinion such an absolutist approach leads to either
stagnation or to code so convoluted as to be unmaintainable.
Breaking compatibility, even in small ways, causes trouble and headaches.
Naturally, non-compatible changes elicit opposition. However, in log4j 1.3,
we are facing problems related to the behavior of appenders when they are
in an erroneous state. My changes are intended to address this problem. I
tried to explain my point of view to Curt over the phone for quite almost
an hour. We seemed to have reached an agreement but one which did not
survive the night. Obviously, you could not have known this when you wrote
your comments.
Your words are quite harsh but I guess it goes with the territory. Keeping
everyone happy is not exactly a piece of cake.
At 05:27 PM 2/26/2005, Mark Masterson wrote:
>Hello Ceki,
>
>Well, I'm not a committer, so experience tells me you'll completely ignore
>my input and pretend as if it had never been voiced.
>
>Nevertheless, as one of those poor schmucks who maintains an Appender
>outside of the log4j base, I do have an opinion about this debate, and it's
>certainly not favorable for you.
>
>The core of Curt's argument, it seems to me, is that you -- dictatorially --
>made these changes without discussing them with the list.
>
>You are now claiming that they were only the beginning of some further
>sweeping changes -- changes which you choose not to describe in any further
>detail.
>
>You are, in effect, asking the comitters to trust you -- blindly -- to make
>infallible judgements with regard to the evolution and design of log4j.
>Your changes will "improve the way appenders work", but you make no effort
>to describe how, or why.
>
>You are a brilliant developer, and there are plenty of historical reasons
>for the committers to grant you the "freedom" that you are asking for.
>Perhaps they will do so, as they often have in the past.
>
>Nevertheless, you do not seem to have grapsed that the underlying issue that
>this event has triggered is social, not technical.
>
>The question that this argument exposes, I find, is the following: Is log4j
>Ceki's project, on which others may be allowed to work? Or is it a true
>collaborative project, on which Ceki just happens to be the founder?
>
>I assume that the comitters will close ranks with you, and will collectively
>force Curt to cease agitating, as has happened with regard to similar events
>in the past. I expect that Curt will "lose" the argument, and that there
>will be no change in the way log4j is managed. I also think that's
>regrettable, and detrimental, and I simply couldn't ignore this opportunity
>to comment on it.
>
>For the record, I agree almost completely with the technical points that
>Curt has raised. You seem to be displaying an alarmingly casual attitude
>towards the distinction between the Appender interface and the
>AppenderSkeleton utility class, and your repeated comments, along the lines
>of "Curt, today there is not a single appender which implements the Appender
>interface without extending the AppenderSkeleton class" reinforce the
>impression that, despite a great deal of hype about logging services, the
>top level project, and so forth, everything that is not a part of "log4j"
>is, from your perspective, a second class citizen.
>
>Cheers,
>Mark
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
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)
Posted by 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)
Posted by 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
Re: Design and evoluton of log4j (Was:
AppenderSkeleton.isActive, etc)
Posted by 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)
Posted by Curt Arnold <ca...@apache.org>.
On Feb 26, 2005, at 11:51 AM, Ceki Gülcü wrote:
> Mark,
>
> Over the years, I have always strived to listen to all the opinions
> voiced. I also try to accommodate opinions diverging from mine and
> when it boils down to a matter of taste, I tend to privilege the
> opinions of others over my own. Certainly, there are examples that go
> both ways.
>
> From a more general perspective, we have to ask ourselves how we want
> to see the log4j code evolve. One approach, apparently advocated Curt,
> consists of religiously preserving 100% and absolute backward
> compatibility. In my opinion such an absolutist approach leads to
> either stagnation or to code so convoluted as to be unmaintainable.
All I have been advocating is that breaking changes require discussion
and voting. I think 100% would be desirable.
>
> Breaking compatibility, even in small ways, causes trouble and
> headaches. Naturally, non-compatible changes elicit opposition.
> However, in log4j 1.3, we are facing problems related to the behavior
> of appenders when they are in an erroneous state. My changes are
> intended to address this problem. I tried to explain my point of view
> to Curt over the phone for quite almost an hour. We seemed to have
> reached an agreement but one which did not survive the night.
I did not feel that my commits after our conversation were inconsistent
with the conversation. I don't recall a change of heart or thinking
that I said one thing and did another. You had pointed out that the
isActive() checks within the doAppend (which had been commented out to
allow Hivemind to pass its tests) were essential for the healthy
operation of the internal appenders, so I attempted to restore that
code without breaking Hivemind and also restore the test code that I
commented out when Appender was reverted.
I did feel that your reversion of those changes and the reinstatement
of the new methods to Appender was inappropriate. Even if you
disagreed, there was no immediate need to revert since my changes posed
no immediate danger to the code base. Apparently, we have different
recollections of that phone call.
> Obviously, you could not have known this when you wrote your comments.
>
> Your words are quite harsh but I guess it goes with the territory.
> Keeping everyone happy is not exactly a piece of cake.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Design and evolution of log4j (Was: AppenderSkeleton.isActive, etc)
Posted by Mark Masterson <ma...@compuserve.com>.
Hi Ceki,
Yes, the tone of my mail was harsh. I find it unfortunate that this was the
case, but I also believe it was necessary. I also believe I can explain
why, if you're willing to listen.
As I've already mentioned, I believe the current discussion is a
manifestation of social issues -- the technical issues are real, and not
unimportant, but by focusing solely on them, we would be ignoring (as has
often been the case in the past) the effects of the social issues that are
running alongside the discussion like a parallel thread. That would be
unfortunate, because the social issues are real, they have real-world
consequences, and they influence (strongly) the so-called "technical"
decisions.
Many people, perhaps most, dislike conflict. Confrontation and conflict are
not activities that most people find pleasurable. One can see
manifestations of that in the recent pleas for us to bring the conversation
back under control, to count to ten, to take a deep breath, and so on.
These are the reasonable attempts, by reasonable people, to defuse and avoid
conflict. This approach is generally a good one -- conflict is a dangerous
tool: it's easy to get hurt while using it, or hurt others, and it's a
notoriously difficult tool to control. Moreover, it's a very difficult tool
to *use* -- it takes an enormous amount of skill, tact and patience to
achieve a useful, productive conflict -- it's nerve wracking. Given this,
it's understandable that many people prefer to avoid using it altogether --
you will see this manifested in comments like "this just isn't worth it to
me".
Sometimes, unfortunately, conflict is *required*. Sometimes, it's simply
the only tool that will do the job.
Ceki, as I pointed out in my first message, you're a brilliant developer.
log4j stands as a testament to your technical skills. But frankly, it's not
my impression that your social skills are on exactly the same level (and I'm
sorry if that offends you, but that's as diplomatic as I can be with that
statement). I've been a lurker on both this and the user list for many
years. I've watched arguments come and go, and observed your "management
style" on many occasions. In my experience (and again, I am forced to be a
bit blunt here), you don't respond well to subtle, quiet approaches. One
has to hit you over the head with a verbal hammer, before you sit up and
take notice. That's my opinion -- there are doubtless others.
Nevertheless, that opinion explains the harsh tone of my first message. It
seems to me that Curt has raised some important, and valid, points.
Further, it seemed to me that you were attempting to steamroller over them,
in a fashion that I have observed you do on more than one occasion in the
past. To cite just two fairly recent examples, I only need two keywords:
"LBEL" and "TRACE". I have repeatedly observed discussions with you, over
technical issues, simply peter out because the protagonists in them lost the
will to continue it. *Your* conversational style, in e-mails, is often
rather harsh and confrontational, although you do not seem to be all that
aware of it. Repeatedly, I have observed disagreements with you conclude,
not because the people who were disagreeing with you had become convinced
that your point of view was correct, but because they simply had lost the
will to continue the discussion. You have, in my opinion, on more than one
occasion in the past, achieved some technical "victory" simply by virtue of
being stubborn and more willing than your opponent to "hang in there" in a
conflict.
You say "I also try to accommodate opinions diverging from mine and when it
boils down to a matter of taste, I tend to privilege the opinions of others
over my own." Well, that sounds good, but how do you define "taste"? The
logic of the sentence I quote suggest that, when the issue is not one that
you judge to be a question of "taste", you utilize some other algorithm to
make a judgment. In my experience, that algorithm can be expressed as "I
know what's best for log4J -- pipe down out there!" :-)
Curt is, in my opinion, quite obviously trying to navigate this mine field
*without* giving up. He is trying valiantly to maintain a conflict with you
that he sees as necessary, *without* being quite as "harsh" as my first mail
was. He is trying to manage the conflict without hitting you on the head
with a verbal hammer.
So I decided to give it try. I felt that, as an outsider, I might be able
to get away with it. It was my hope that by doing so, I would provoke the
other committers to chime in and say *something* -- ANYTHING -- rather than
simply stand on the sidelines and hope that Curt could handle it alone.
Given the reactions of some of the other folks on this list today, it seems
I was successful.
I believe this is an important discussion. What is the nature of the log4j
project, as an open source effort? Is it like Linus and the Linux kernel --
others may participate, but ultimately, YOU make the decisions? That's
certainly a valid model, but if that's how it works, you should SAY SO.
However, if that's not how you want it to work, then this discussion is
critical to validating and defining the "protocol" that others need to use
to navigate disagreements with you.
I have a lot of respect for you, and am a devoted fan of your software. I
hope you will take my words seriously, but not personally, and that
something positive will emerge from the discussion.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org