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 Curt Arnold <ca...@apache.org> on 2005/02/25 00:23:01 UTC
AppenderSkeleton.isActive, etc
I've committed some tweaks that I think should leave us in pretty good
condition. I've modified the Gump descriptor for Cactus so that it
should attempt to build against log4j 1.2 tonight which should allow us
to tell if the recent breakage was due our recent changes.
I've restored the test of isActive in doAppend and the problematic
statements in AbstractAppenderTest. To make these work, I've added
explicit constructors for AppenderSkeleton. Code that uses the default
AppenderSkeleton constructor will be created with active = true which
should result in behavior consistent with 1.2 for custom appenders. If
a custom appender did not require activateOptions to be called, it will
still work and if it did require a call to activateOptions and none was
made, it will still fail in the same manner. All log4j classes (with
the exception of Chainsaw classes) that derive from AppenderSkeleton
call AppenderSkeleton(boolean isActive) which indicates whether they
are ready to process events immediately after construction. I didn't
change the chainsaw appenders due to the recent migration and they
should work consistently with their previous behavior. I did not
intend to change the appenders in the contribution sections and will
revert them later this evening.
In AbstractAppenderTest, I changed the type used in the tests from
Appender to AppenderSkeleton. All the classes tested by
AbstractAppenderTest are known to be inherited from AppenderSkeleton.
The message dispatching code does not currently need to know whether an
appender is active or closed, it just calls append and assumes that the
appender does something appropriate with its state. I don't see any
need at this time to break any (possibly hypothetical) implementations
of Appender that don't extend AppenderSkeleton.
I'm not sure about the duality of activate and activateOptions. It
seems likely that there could be a problem when classes mix and match
which methods they override. It may be better to change the
implementations back to activateOptions and provide a final activate
method that delegates to activateOptions. However, I did not work
through the permutations.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 25, 2005, at 1:03 PM, Curt Arnold wrote:
>
> This would result in a call to AppenderSkeleton.activate() and a call
> to AppenderSkeleton.activateOptions() since activateOptions would
> invoke the custom appenders activation code. If code wants to work
> properly with existing custom appenders, then it should call
> activateOptions since that is the only call that works correctly with
> both internal and existing custom appenders, but it is deprecated and
> the JavaHelp tells you to call the method that may be unsafe with
> existing custom appenders.
>
Should have been:
> This would result in a call to AppenderSkeleton.activate() and a call
> to AppenderSkeleton.activateOptions() having different effects
> since...
---------------------------------------------------------------------
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 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 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
Re: Design and evoluton of log4j (Was:
AppenderSkeleton.isActive, etc)
Posted by Ceki Gülcü <ce...@qos.ch>.
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
Design and evoluton of log4j (Was: AppenderSkeleton.isActive, etc)
Posted by Mark Masterson <ma...@compuserve.com>.
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
RE: [VOTE] Additions to the Appender interface
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> Unfortunately having both activate (overriden by internal appenders)
> and activateOptions (overriden by existing custom appenders) can make
> it extremely complicated to have a complex appender that performs the
> exact same actions for both activate() and activateOptions(). I have
> no problem with AppenderSkeleton.activate being a final method that
> invokes AppenderSkeleton.activateOptions.
Yup, that's fine too.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Curt Arnold <ca...@apache.org>.
On Feb 28, 2005, at 1:15 PM, Yoav Shapira wrote:
> - Mark activateOptions in Appender deprecated, with a prominent notice
> that
> it is slated for future removal and has been replaced by the activate
> method
> in AppenderLifecycle interface.
Unfortunately having both activate (overriden by internal appenders)
and activateOptions (overriden by existing custom appenders) can make
it extremely complicated to have a complex appender that performs the
exact same actions for both activate() and activateOptions(). I have
no problem with AppenderSkeleton.activate being a final method that
invokes AppenderSkeleton.activateOptions.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Paul Smith <ps...@aconex.com>.
[X] Refuse those additions - in favour of Yoav's proposal (plus Curt's suggestion of activate being final method in AppenderSkeleton). If this does not get us what we want and does not have a significant burden on us, then I'm in favour of revisting the issue as a group
I was going to suggest an "Appender2" sub-interface until I saw how lame that was in comparison...
Paul
Yoav Shapira wrote:
>Hi,
>
>
>
>>[1] http://marc.theaimsgroup.com/?l=log4j-dev&m=110874743313972&w=2
>>[2] http://marc.theaimsgroup.com/?l=log4j-dev&m=110875656008077&w=2
>>
>>
>
>OK, thanks, that was very useful.
>
><vote>
>[] Accept the additions to the Appender interface [X] Refuse those additions
>[ ] Abstain </vote>
>
>I suggest the following:
>
>- Add new AppenderLifecycle interface. This interface would have methods
>like activate(), isActive(), isClosed(), and would be the future way to add
>more lifecycle-related stuff.
>
>- Mark activateOptions in Appender deprecated, with a prominent notice that
>it is slated for future removal and has been replaced by the activate method
>in AppenderLifecycle interface.
>
>- Make AppenderSkeleton (and other classes if necessary) implement
>AppenderLifecycle as needed.
>
>Yoav
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
RE: [VOTE] Additions to the Appender interface
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> [1] http://marc.theaimsgroup.com/?l=log4j-dev&m=110874743313972&w=2
> [2] http://marc.theaimsgroup.com/?l=log4j-dev&m=110875656008077&w=2
OK, thanks, that was very useful.
<vote>
[] Accept the additions to the Appender interface [X] Refuse those additions
[ ] Abstain </vote>
I suggest the following:
- Add new AppenderLifecycle interface. This interface would have methods
like activate(), isActive(), isClosed(), and would be the future way to add
more lifecycle-related stuff.
- Mark activateOptions in Appender deprecated, with a prominent notice that
it is slated for future removal and has been replaced by the activate method
in AppenderLifecycle interface.
- Make AppenderSkeleton (and other classes if necessary) implement
AppenderLifecycle as needed.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Additions to the Appender interface
Posted by Ceki Gülcü <ce...@qos.ch>.
Yoav,
http://cvs.apache.org is currently down so the information contained in CVS
notification messages is the best we currently have.
The changes in question are contained in the CVS notification message [1].
Of particular interest are the changes between revision 1.17 and 1.16 in
the Appender interface and the changes between revision 1.35 and 1.36 in
AppenderSkeleton.java. A subsequent commit message [1] which includes
associated test cases may also be of interest.
[1] http://marc.theaimsgroup.com/?l=log4j-dev&m=110874743313972&w=2
[2] http://marc.theaimsgroup.com/?l=log4j-dev&m=110875656008077&w=2
At 07:37 PM 2/28/2005, Yoav Shapira wrote:
>Hi,
>Can we have a complete list of the changes being voted upon please? I'd
>like to see it in one place before I vote. I'd also like to make sure
>alternatives are explored, although they probably have been already. For
>example, have an AppenderActivity interface with isClosed/isActive, and have
>AppenderSkeleton implement both Appender and AppenderActivity, rather than
>add these methods to the Appender interface itself.
>
>No class or interface is completely untouchable. But modifications to core
>pieces should have great and significant benefits to offset the cost needed
>in user effort.
>
>Yoav
--
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: [VOTE] Additions to the Appender interface
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:31 PM 2/28/2005, Curt Arnold wrote:
>On Feb 28, 2005, at 12:14 PM, Ceki Gülcü wrote:
>
>>
>>Curt, your -1 vote is duly registered as blocking and valid. As per our
>>bylaws [1], a lazy majority, that is three (3) +1 votes and more +1 votes
>>than -1 votes, is required to unblock the situation.
>>
>>I hereby formally request the committers to cast their vote so we can
>>move forward.
>>
>><vote>
>>[X] Accept the additions to the Appender interface
>>[ ] Refuse those additions
>>[ ] Abstain
>></vote>
>>
>>Usually 72 hours are allocated for votes. I think leaving the ballot open
>>until Friday evening should allow everyone to participate. Many thanks in
>>advance,
>
>The additions to the Appender interface were only part of my
>objections. The others were the renaming of
>AppenderSkeleton.activateOptions to AppenderSkeleton.activate and the new
>requirement that extensions of AppenderSkeleton have activateOptions
>called. I do not know whether you intend to have separate votes on those
>issues or if this vote was intended to covers all of those issues.
This vote was intended to cover all issues in relation to the
additions/changes to the Appender interface. Please consider the term
"additions" to cover changes as well, in particular the replacement of the
activateOptions() method by activate().
--
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: [VOTE] Additions to the Appender interface
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
Can we have a complete list of the changes being voted upon please? I'd
like to see it in one place before I vote. I'd also like to make sure
alternatives are explored, although they probably have been already. For
example, have an AppenderActivity interface with isClosed/isActive, and have
AppenderSkeleton implement both Appender and AppenderActivity, rather than
add these methods to the Appender interface itself.
No class or interface is completely untouchable. But modifications to core
pieces should have great and significant benefits to offset the cost needed
in user effort.
Yoav
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Monday, February 28, 2005 1:31 PM
> To: Log4J Developers List
> Subject: Re: [VOTE] Additions to the Appender interface
>
>
> On Feb 28, 2005, at 12:14 PM, Ceki Gülcü wrote:
>
> >
> > Curt, your -1 vote is duly registered as blocking and valid. As per
> > our bylaws [1], a lazy majority, that is three (3) +1 votes and more
> > +1 votes than -1 votes, is required to unblock the situation.
> >
> > I hereby formally request the committers to cast their vote so we can
> > move forward.
> >
> > <vote>
> > [X] Accept the additions to the Appender interface
> > [ ] Refuse those additions
> > [ ] Abstain
> > </vote>
> >
> > Usually 72 hours are allocated for votes. I think leaving the ballot
> > open until Friday evening should allow everyone to participate. Many
> > thanks in advance,
> >
>
> The additions to the Appender interface were only part of my
> objections. The others were the renaming of
> AppenderSkeleton.activateOptions to AppenderSkeleton.activate and the
> new requirement that extensions of AppenderSkeleton have
> activateOptions called. I do not know whether you intend to have
> separate votes on those issues or if this vote was intended to covers
> all of those issues.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Curt Arnold <ca...@apache.org>.
On Feb 28, 2005, at 12:14 PM, Ceki Gülcü wrote:
>
> Curt, your -1 vote is duly registered as blocking and valid. As per
> our bylaws [1], a lazy majority, that is three (3) +1 votes and more
> +1 votes than -1 votes, is required to unblock the situation.
>
> I hereby formally request the committers to cast their vote so we can
> move forward.
>
> <vote>
> [X] Accept the additions to the Appender interface
> [ ] Refuse those additions
> [ ] Abstain
> </vote>
>
> Usually 72 hours are allocated for votes. I think leaving the ballot
> open until Friday evening should allow everyone to participate. Many
> thanks in advance,
>
The additions to the Appender interface were only part of my
objections. The others were the renaming of
AppenderSkeleton.activateOptions to AppenderSkeleton.activate and the
new requirement that extensions of AppenderSkeleton have
activateOptions called. I do not know whether you intend to have
separate votes on those issues or if this vote was intended to covers
all of those issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Curt Arnold <ca...@apache.org>:
> Unless someone else wants to volunteer for the task, I'll back out the
> additions to the appender interface and the activateOptions rename.
>
I think you are the obvious one to make these changes since it was your proposal
to keep backward compatibility, so go ahead.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Curt Arnold <ca...@apache.org>.
Unless someone else wants to volunteer for the task, I'll back out the
additions to the appender interface and the activateOptions rename.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Additions to the Appender interface
Posted by Ceki Gülcü <ce...@qos.ch>.
It is fairly obvious that Curt's veto was sustained by all voters except
for me. I'll comment on the vote after I sort out more urgent tasks, such
as tax return and other really "interesting" administravia.
At 07:14 PM 2/28/2005, Ceki Gülcü wrote:
>Curt, your -1 vote is duly registered as blocking and valid. As per our
>bylaws [1], a lazy majority, that is three (3) +1 votes and more +1 votes
>than -1 votes, is required to unblock the situation.
>
>I hereby formally request the committers to cast their vote so we can move
>forward.
>
><vote>
>[X] Accept the additions to the Appender interface
>[ ] Refuse those additions
>[ ] Abstain
></vote>
>
>Usually 72 hours are allocated for votes. I think leaving the ballot open
>until Friday evening should allow everyone to participate. Many thanks in
>advance,
>
>[1] http://logging.apache.org/site/bylaws.html
--
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: [VOTE] Additions to the Appender interface
Posted by Jacob Kjome <ho...@visi.com>.
<vote>
[ ] Accept the additions to the Appender interface
[X] Refuse those additions
[ ] Abstain
</vote>
It is apparent that there are clear ways to avoid incompatibility and make
improvements to appenders at the same time. The suggestions by both Curt and
Yoav ought be be explored. If it turns out that they, in fact, hinder new
development of needed features, then I may think about changing my vote. For
now, let's try not to cause unnecessary incompatibilities.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[VOTE] Additions to the Appender interface
Posted by Ceki Gülcü <ce...@qos.ch>.
Curt, your -1 vote is duly registered as blocking and valid. As per our
bylaws [1], a lazy majority, that is three (3) +1 votes and more +1 votes
than -1 votes, is required to unblock the situation.
I hereby formally request the committers to cast their vote so we can move
forward.
<vote>
[X] Accept the additions to the Appender interface
[ ] Refuse those additions
[ ] Abstain
</vote>
Usually 72 hours are allocated for votes. I think leaving the ballot open
until Friday evening should allow everyone to participate. Many thanks in
advance,
[1] http://logging.apache.org/site/bylaws.html
At 06:25 PM 2/28/2005, Curt Arnold wrote:
>In this particular instance, I would -1 both the additions to the Appender
>interface and the renaming of the activateOptions virtual method. The
>objectives of both (as have been revealed so far) could be accomplished
>without breaking backwards compatibility with very minimal additional
>complexity.
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 28, 2005, at 10:00 AM, Ceki Gülcü wrote:
> Curt's changes preserve absolute backward compatibility. Although
> quite reasonable, they add an additional layer of
> complexity. Preserving backward compatibility is a very important
> goal. At the same time, it can eventually lead to over-convoluted and
> unmaintainable code. In my opinion, it is more economical to ask
> authors of appenders to make small updates to their code in order to
> adapt to changes in log4j 1.3. Note that we are talking about small,
> easily performed adaptations. I believe that trying to preserve
> *perfect* backward compatibility is beyond our resources.
>
> To summarize, I think that log4j committers have to choose between:
>
> 1) For the sake of improvement, we allow for small changes, even in
> core interfaces, at the cost of perfect backward compatibility.
>
> 2) No, perfect backward compatibility is an overriding principle, more
> important than other considerations.
>
> Comments?
>
It shouldn't be a decision between an absolute fanatical perfect
backwards compatibility and total chaos. However if I had to choose
one at this time I would choose fanatical backwards compatibility.
What I have been suggesting is that our general policy is to preserve
backwards compatibility and that we discuss any exceptions either on
discovery or prior to committing and require a vote when we knowingly
break backwards compatibility.
A substantial proportion of code that uses log4j has to run in the
context of another application or server and has no control over the
version of log4j that is in use. I think it highly desirable that code
that worked properly with 1.2 would continue to work properly. If
there are compelling reasons and no reasonable alternative, we could
consider adding additional requirements (like adding the detach method
RepositorySelector) that can work under both 1.2 and 1.3. Only under
the most extraordinary conditions, should we be forcing applications to
choose between 1.2 and 1.3 or to add substantial complexity to be able
to operate in both environments.
As I mentioned in a previous email, it appears that several significant
projects have found themselves having to choose between 1.2 and 1.3.
We should review the problems that they encountered and attempt to
resolve them. They are serving as advance warning of the problems that
will be encountered in much greater number as log4j 1.3 is evaluated by
the wider body of log4j users. Breaking Hivemind may not be a big
deal, but it may be a warning that we are breaking 10 or 100 times the
number of non-ASF applications.
At this point I would consider the "core" interfaces like Appender and
Layout nearly untouchable. The have proven that they are sufficient to
represent the essential characteristics of their abstraction. Any
additional enhancement or optimization could be exposed using
additional interfaces or hidden within implementations.
In this particular instance, I would -1 both the additions to the
Appender interface and the renaming of the activateOptions virtual
method. The objectives of both (as have been revealed so far) could be
accomplished without breaking backwards compatibility with very minimal
additional complexity.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
We all agree that the discussion got unnecessarily heated. I also
recognize that it would have been better to hold a discussion before
proceeding with my additions to the Appender interface, rather than
the other way around. The level of the reaction was well beyond what I
had anticipated, especially considering that they seemed backward
compatible, although later this assertion was shown to be inexact.
Presently, we are confronted with a situation where an appender in an
erroneous state can behave erratically, for example by flooding the
output of other appenders or entering endless loops.
As there are many appenders out there representing a relatively large
body of code. They share common attributes but also have small
differences. To verify that appenders function reasonably even under
exceptional (erroneous) conditions, I started to write a battery of
tests verifying this for each appender implementation. As you are
probably aware, it is much easier to test code which reveals some
information about internal state as opposed to completely opaque
boxes. A little more transparency is the rationale behind the addition
of the isActive(), isClosed() methods to the Appender interface.
I also added an internal check in AppenderSkeleton which
short-circuited invoking appenders reportedly in an erroneous,
i.e. inactive, state. This is the change that broke the Hivemind test
which was subsequently caught by Gump.
Curt's changes preserve absolute backward compatibility. Although
quite reasonable, they add an additional layer of
complexity. Preserving backward compatibility is a very important
goal. At the same time, it can eventually lead to over-convoluted and
unmaintainable code. In my opinion, it is more economical to ask
authors of appenders to make small updates to their code in order to
adapt to changes in log4j 1.3. Note that we are talking about small,
easily performed adaptations. I believe that trying to preserve
*perfect* backward compatibility is beyond our resources.
To summarize, I think that log4j committers have to choose between:
1) For the sake of improvement, we allow for small changes, even in
core interfaces, at the cost of perfect backward compatibility.
2) No, perfect backward compatibility is an overriding principle, more
important than other considerations.
Comments?
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
> People,
>
> I can't get work done without having it reverted a few days later.
I don't recall other incidences. In this case, a set of changes was
brought to our attention as causing Hivemind project to fail and I
think it justified reverting the changes until we analyzed the
situation. I did give a few hours heads up of my intent to revert and
got support of another committer. I waited until it was getting close
to the cut-off point for the night's Gump run to revert, but got Ceki's
objections a few minutes later. I didn't undertake the reversion
lightly and don't recall any other times I've reverted another
committer's change on log4j.
> In the last few days, I started working on improving the Appender
> interface in preparation for a much larger body of improvements.
> Unfortunately, the work got stalled. Now, there are complaints voiced
> about the newly introduced methods in Appender not being useful. Of
> course they are not useful as I did not get a chance to complete the
> work I started.
The interface change was wrongly identified as the reason for the
breakage
(http://marc.theaimsgroup.com/?l=log4j-dev&m=110907566916123&w=2). The
obvious question was why these methods were added.
>
> We have to put a stop for this type of continuos haggling. We have
> work to do and it won't get done if we politicize every little detail.
> These frequency of these debates is approaching the level of the
> intolerable.
>
> I would like to ask the log4j committers to grant me the freedom to
> improve the way appenders work and to consolidate their lifecycle into
> something well defined and robust.
>
> Do I have your support in this endeavor?
>
I think this work may justify creating a branch for this work till it
is ready for consideration to be integrated with CVS HEAD. I
understand how complex the issues that you are trying to work through
are and how it may be difficult to explain how all the pieces may fit
together until you are further along. However, since the stated goal
was for 1.3 to be drop-in compatible with 1.2, there should not be any
intentional changes on CVS HEAD that break compatibility (even
hypothetically) without discussion and if needed, voting.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Paul Smith <ps...@aconex.com>.
Ceki,
I would have thought making changes to such a core interface with
potential backward compatability issues may have started with a
discussion. We don't know what the usefulness of the changes are
because you haven't told us. It's highly likely that once you've told
us your plan, we will completely agree with you.
Paul
Ceki Gülcü wrote:
> At 02:19 AM 2/26/2005, Curt Arnold wrote:
>
>> On Feb 25, 2005, at 6:57 PM, Paul Smith wrote:
>>
>>> Appender the interface is the contract for all Appenders,
>>> AppenderSkeleton just happens to provide some decent plumbing and
>>> support in an effort to make it easy to write a custom appender.
>>>
>>> Anywhere within log4j we should think Appender, and forget about the
>>> existence of AppenderSkeleton. Changing the contract of the
>>> interface should be done with extreme caution.
>>> However, if changing the contract is for good reasons, then I am in
>>> favour of it, as long as we provide good documentation about "Why my
>>> custom appender doesn't work in 1.3" in big bold flashing lights.
>>> Paul
>>
>>
>> At the present, I don't think the proposed changes to Appender are
>> justified or beneficial. They are not used within log4j itself, they
>> are only used within a new test case (AbstractAppenderTest) that
>> could have been written in terms of AppenderSkeleton since it tests
>> details of the AppenderSkeleton implementation that have not been
>> part of the Appender contract.
>
>
> People,
>
> I can't get work done without having it reverted a few days later. In
> the last few days, I started working on improving the Appender
> interface in preparation for a much larger body of improvements.
> Unfortunately, the work got stalled. Now, there are complaints voiced
> about the newly introduced methods in Appender not being useful. Of
> course they are not useful as I did not get a chance to complete the
> work I started.
>
> We have to put a stop for this type of continuos haggling. We have
> work to do and it won't get done if we politicize every little detail.
> These frequency of these debates is approaching the level of the
> intolerable.
>
> I would like to ask the log4j committers to grant me the freedom to
> improve the way appenders work and to consolidate their lifecycle into
> something well defined and robust.
>
> Do I have your support in this endeavor?
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:19 AM 2/26/2005, Curt Arnold wrote:
>On Feb 25, 2005, at 6:57 PM, Paul Smith wrote:
>
>>Appender the interface is the contract for all Appenders,
>>AppenderSkeleton just happens to provide some decent plumbing and support
>>in an effort to make it easy to write a custom appender.
>>
>>Anywhere within log4j we should think Appender, and forget about the
>>existence of AppenderSkeleton. Changing the contract of the interface
>>should be done with extreme caution.
>>However, if changing the contract is for good reasons, then I am in
>>favour of it, as long as we provide good documentation about "Why my
>>custom appender doesn't work in 1.3" in big bold flashing lights.
>>Paul
>
>At the present, I don't think the proposed changes to Appender are
>justified or beneficial. They are not used within log4j itself, they are
>only used within a new test case (AbstractAppenderTest) that could have
>been written in terms of AppenderSkeleton since it tests details of the
>AppenderSkeleton implementation that have not been part of the Appender
>contract.
People,
I can't get work done without having it reverted a few days later. In the
last few days, I started working on improving the Appender interface in
preparation for a much larger body of improvements. Unfortunately, the work
got stalled. Now, there are complaints voiced about the newly introduced
methods in Appender not being useful. Of course they are not useful as I
did not get a chance to complete the work I started.
We have to put a stop for this type of continuos haggling. We have work to
do and it won't get done if we politicize every little detail. These
frequency of these debates is approaching the level of the intolerable.
I would like to ask the log4j committers to grant me the freedom to improve
the way appenders work and to consolidate their lifecycle into something
well defined and robust.
Do I have your support in this endeavor?
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 25, 2005, at 6:57 PM, Paul Smith wrote:
> Appender the interface is the contract for all Appenders,
> AppenderSkeleton just happens to provide some decent plumbing and
> support in an effort to make it easy to write a custom appender.
>
> Anywhere within log4j we should think Appender, and forget about the
> existence of AppenderSkeleton. Changing the contract of the interface
> should be done with extreme caution.
> However, if changing the contract is for good reasons, then I am in
> favour of it, as long as we provide good documentation about "Why my
> custom appender doesn't work in 1.3" in big bold flashing lights.
> Paul
>
At the present, I don't think the proposed changes to Appender are
justified or beneficial. They are not used within log4j itself, they
are only used within a new test case (AbstractAppenderTest) that could
have been written in terms of AppenderSkeleton since it tests details
of the AppenderSkeleton implementation that have not been part of the
Appender contract.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Paul Smith <ps...@aconex.com>.
Appender the interface is the contract for all Appenders,
AppenderSkeleton just happens to provide some decent plumbing and
support in an effort to make it easy to write a custom appender.
Anywhere within log4j we should think Appender, and forget about the
existence of AppenderSkeleton. Changing the contract of the interface
should be done with extreme caution.
However, if changing the contract is for good reasons, then I am in
favour of it, as long as we provide good documentation about "Why my
custom appender doesn't work in 1.3" in big bold flashing lights.
Paul
Curt Arnold wrote:
>
> On Feb 25, 2005, at 3:22 PM, Ceki Gülcü wrote:
>
>> At 09:48 PM 2/25/2005, Curt Arnold wrote:
>>
>>> I can't stress how strongly that I believe these changes are bad and
>>> will unnecessarily cause some users of 1.2 to stay with log4j 1.2 or
>>> encounter broken behavior during the migration. I was disappointed
>>> that such significant changes were initially committed (back on the
>>> 18th) without any prior discussion or announcement. If I missed it,
>>> I apologize.
>>
>>
>> I understand. OK, to summarize:
>>
>> 1) The changes are compile-time backward compatible -- existing
>> appenders will compile just fine without change against 1.2 as well
>> as 1.3.
>
>
> Existing appenders that derive from AppenderSkeleton will compile.
> Any, at this point hypothetical, appenders that directly implemented
> Appender without extending AppenderSkeleton will fail to compile.
>
>>
>> 2) The changes only affect programmatic calls to appenders maintained
>> outside the log4j project. If those appenders are invoked from log4j
>> configuration files, then they will work just fine and without change
>> with 1.2 as well as 1.3.
>
>
> I haven't confirmed it, but from code review it appears that any
> existing custom appended that implemented activateOptions will not be
> properly initialized from configuration files, since ConfigurationBase
> calls activate, not activateOptions. For a custom appender that
> required activateOptions and wanted to work with both log4j 1.2 and
> 1.3, it appears that the would have to implement both activateOptions
> and activate and avoid calling one from the other to avoid loops but
> avoid doing activation twice for one call. Let me know if you want be
> to build a test case to check this.
>
>
>>
>> 3) Applications such as hivemind which configure their custom
>> appenders programmatically need to add one line to their code in
>> order to invoke the activateOptions() method. If they do that, they
>> will be compatible with both 1.2 and 1.3.
>
>
> For Appenders that are ready at construction, they would more likely
> do what you did for tests/.../VectorAppender and just call
> super.activate() in the constructor.
>
> By adding both AppenderSkeleton() and AppenderSkeleton(boolean), we
> allow existing custom to continue to work consistent with 1.2 and
> allow internal implementations to take advantage of the check that
> activate/activateOptions has been called. If we wanted to encourage
> custom appenders to migrate away from the compatibility behavior, then
> we could mark the default AppenderSkeleton constructor as deprecated.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 26, 2005, at 10:00 AM, Ceki Gülcü wrote:
>
> Curt, today there is not a single appender which implements the
> Appender interface without extending the AppenderSkeleton class.
>
All we know for sure is the code in the Gump universe. The Appender
interface is complex enough that it would drive almost all
implementations to subclass AppenderSkeleton. But is isn't impossible
and wasn't discouraged. If someone implemented a remote appender using
RMI or Soap, they may have only exposed the Appender interface.
>>> 2) The changes only affect programmatic calls to appenders
>>> maintained outside the log4j project. If those appenders are invoked
>>> from log4j configuration files, then they will work just fine and
>>> without change with 1.2 as well as 1.3.
>>
>> I haven't confirmed it, but from code review it appears that any
>> existing custom appended that implemented activateOptions will not be
>> properly initialized from configuration files, since
>> ConfigurationBase calls activate, not activateOptions. For a custom
>> appender that required activateOptions and wanted to work with both
>> log4j 1.2 and 1.3, it appears that the would have to implement both
>> activateOptions and activate and avoid calling one from the other to
>> avoid loops but avoid doing activation twice for one call. Let me
>> know if you want be to build a test case to check this.
>
> You have a point there. However, things are not as bad as you depict
> nor as rosy as I asserted previously. Existing appenders would need to
> rename their activatOptions() method as activate(). I think that's an
> acceptable price to pay. When a software product changes for the
> better, it's extensions need to change as well. Client code won't see
> the difference as long as the appenders they use adapt to changes in
> 1.3. Adapting existing appenders involves minimal easy to perform
> changes. (It took about 10 minutes to perform on the dozen or so
> appenders shipping with log4j proper.)
However, you were making a deliberate decision that those appenders
would only work with 1.3 (which is appropriate since they are part of
the log4j package). However, users of custom appenders may not have
the choice of what version of log4j they work under. Even if they are
committed to migrate to 1.3, they may want to run under both 1.2 and
1.3 for a period of time to test the migration. At least for some
class of appenders, it may be extremely complicated to write activate
and activateOptions so they behave identically.
I agree that activateOptions is not the best name, but it is an
established extension point and custom appender writers have probably
gotten use to it. I would have no problem with adding a
public final void activate() {
activateOptions();
}
to AppenderSkeleton so that Appender users could have a synonym for
activateOptions.
>
>>> 3) Applications such as hivemind which configure their custom
>>> appenders programmatically need to add one line to their code in
>>> order to invoke the activateOptions() method. If they do that, they
>>> will be compatible with both 1.2 and 1.3.
>>
>> For Appenders that are ready at construction, they would more likely
>> do what you did for tests/.../VectorAppender and just call
>> super.activate() in the constructor.
>>
>> By adding both AppenderSkeleton() and AppenderSkeleton(boolean), we
>> allow existing custom to continue to work consistent with 1.2 and
>> allow internal implementations to take advantage of the check that
>> activate/activateOptions has been called. If we wanted to encourage
>> custom appenders to migrate away from the compatibility behavior,
>> then we could mark the default AppenderSkeleton constructor as
>> deprecated.
>
> It's a matter of taste and priorities. IMHO going into all these
> contortions does not pay off. We can't behave as if we had a yearly
> development budget of 20 million USD with 50 developers on the
> project. We don't have that kind of resources. Subsequently, we have
> to keep things simple for the sake of current developers as well as
> future ones.
>
I think it was all of 10 non-comment lines (two AppenderSkeleton
constructors and adding calls to super(false) in about 6 derived
classes) that would eliminate a known problem area while still
preserving the behavior that you desired with the built-in appenders.
I would much rather write and maintain those lines instead of
repeatedly explaining on the situation log4j-user.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:01 AM 2/26/2005, Curt Arnold wrote:
>On Feb 25, 2005, at 3:22 PM, Ceki Gülcü wrote:
>
>>At 09:48 PM 2/25/2005, Curt Arnold wrote:
>>
>>>I can't stress how strongly that I believe these changes are bad and
>>>will unnecessarily cause some users of 1.2 to stay with log4j 1.2 or
>>>encounter broken behavior during the migration. I was disappointed that
>>>such significant changes were initially committed (back on the 18th)
>>>without any prior discussion or announcement. If I missed it, I apologize.
>>
>>I understand. OK, to summarize:
>>
>>1) The changes are compile-time backward compatible -- existing appenders
>>will compile just fine without change against 1.2 as well as 1.3.
>
>Existing appenders that derive from AppenderSkeleton will compile.
>Any, at this point hypothetical, appenders that directly implemented
>Appender without extending AppenderSkeleton will fail to compile.
Curt, today there is not a single appender which implements the Appender
interface without extending the AppenderSkeleton class.
>>2) The changes only affect programmatic calls to appenders maintained
>>outside the log4j project. If those appenders are invoked from log4j
>>configuration files, then they will work just fine and without change
>>with 1.2 as well as 1.3.
>
>I haven't confirmed it, but from code review it appears that any existing
>custom appended that implemented activateOptions will not be properly
>initialized from configuration files, since ConfigurationBase calls
>activate, not activateOptions. For a custom appender that required
>activateOptions and wanted to work with both log4j 1.2 and 1.3, it appears
>that the would have to implement both activateOptions and activate and
>avoid calling one from the other to avoid loops but avoid doing activation
>twice for one call. Let me know if you want be to build a test case to
>check this.
You have a point there. However, things are not as bad as you depict nor as
rosy as I asserted previously. Existing appenders would need to rename
their activatOptions() method as activate(). I think that's an acceptable
price to pay. When a software product changes for the better, it's
extensions need to change as well. Client code won't see the difference as
long as the appenders they use adapt to changes in 1.3. Adapting existing
appenders involves minimal easy to perform changes. (It took about 10
minutes to perform on the dozen or so appenders shipping with log4j proper.)
>>3) Applications such as hivemind which configure their custom appenders
>>programmatically need to add one line to their code in order to invoke
>>the activateOptions() method. If they do that, they will be compatible
>>with both 1.2 and 1.3.
>
>For Appenders that are ready at construction, they would more likely do
>what you did for tests/.../VectorAppender and just call super.activate()
>in the constructor.
>
>By adding both AppenderSkeleton() and AppenderSkeleton(boolean), we allow
>existing custom to continue to work consistent with 1.2 and allow internal
>implementations to take advantage of the check that
>activate/activateOptions has been called. If we wanted to encourage
>custom appenders to migrate away from the compatibility behavior, then we
>could mark the default AppenderSkeleton constructor as deprecated.
It's a matter of taste and priorities. IMHO going into all these
contortions does not pay off. We can't behave as if we had a yearly
development budget of 20 million USD with 50 developers on the project. We
don't have that kind of resources. Subsequently, we have to keep things
simple for the sake of current developers as well as future ones.
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 25, 2005, at 3:22 PM, Ceki Gülcü wrote:
> At 09:48 PM 2/25/2005, Curt Arnold wrote:
>
>> I can't stress how strongly that I believe these changes are bad and
>> will unnecessarily cause some users of 1.2 to stay with log4j 1.2 or
>> encounter broken behavior during the migration. I was disappointed
>> that such significant changes were initially committed (back on the
>> 18th) without any prior discussion or announcement. If I missed it,
>> I apologize.
>
> I understand. OK, to summarize:
>
> 1) The changes are compile-time backward compatible -- existing
> appenders will compile just fine without change against 1.2 as well as
> 1.3.
Existing appenders that derive from AppenderSkeleton will compile.
Any, at this point hypothetical, appenders that directly implemented
Appender without extending AppenderSkeleton will fail to compile.
>
> 2) The changes only affect programmatic calls to appenders maintained
> outside the log4j project. If those appenders are invoked from log4j
> configuration files, then they will work just fine and without change
> with 1.2 as well as 1.3.
I haven't confirmed it, but from code review it appears that any
existing custom appended that implemented activateOptions will not be
properly initialized from configuration files, since ConfigurationBase
calls activate, not activateOptions. For a custom appender that
required activateOptions and wanted to work with both log4j 1.2 and
1.3, it appears that the would have to implement both activateOptions
and activate and avoid calling one from the other to avoid loops but
avoid doing activation twice for one call. Let me know if you want be
to build a test case to check this.
>
> 3) Applications such as hivemind which configure their custom
> appenders programmatically need to add one line to their code in order
> to invoke the activateOptions() method. If they do that, they will be
> compatible with both 1.2 and 1.3.
For Appenders that are ready at construction, they would more likely do
what you did for tests/.../VectorAppender and just call
super.activate() in the constructor.
By adding both AppenderSkeleton() and AppenderSkeleton(boolean), we
allow existing custom to continue to work consistent with 1.2 and allow
internal implementations to take advantage of the check that
activate/activateOptions has been called. If we wanted to encourage
custom appenders to migrate away from the compatibility behavior, then
we could mark the default AppenderSkeleton constructor as deprecated.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: AppenderSkeleton.isActive, etc
Posted by Andy McBride <an...@dsl.pipex.com>.
On Fri, 25 Feb 2005 22:22:19 +0100 Ceki Gülcü <ce...@qos.ch> wrote:
> I understand. OK, to summarize:
>
> 1) The changes are compile-time backward compatible -- existing appenders
> will compile just fine without change against 1.2 as well as 1.3.
>
> 2) The changes only affect programmatic calls to appenders maintained
> outside the log4j project. If those appenders are invoked from log4j
> configuration files, then they will work just fine and without
> change with
> 1.2 as well as 1.3.
On a previous thread on this list it was stated:
"Our guarantee to users consists of maintaining compile-time and run-time
compatibility between their code and various log4j versions. This means
that if users decide to upgrade to 1.3 from 1.2.x, their code should run
without problems. On the other hand, we *try* to maintain (but do not
guarantee) Java serialization compatibility between log4j versions."
Log4j users may have assumed that this applied to their code whether it
is initialised programmatically or via configuration file.
Many OS libraries only have a programmatic API and are expected to provide
compatibility through it.
Configuration of log4j by configuration files is a great help for probably
95% of users, but if someone has felt the need to programmatically
initialise
log4j components and has gone to the trouble of getting it to work using 1.2
then it should also work in 1.3.
>
> 3) Applications such as hivemind which configure their custom appenders
> programmatically need to add one line to their code in order to
> invoke the
> activateOptions() method. If they do that, they will be compatible with
> both 1.2 and 1.3.
One line can be all it takes for it to become a problem in some places :-)
> I'd just like to move forward with code that we can maintain on
> the long term.
>
Keeping the code simple is a noble aim and providing compatibility with old
code usually involves adding complexity and maintenance costs.
Retaining complete drop-in compatibility (excluding serialization) between
1.2 and 1.3 will tempt more to upgrade, reports of problems may put many
off.
Please continue the discussion :-)
Kind Regards
Andy
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:48 PM 2/25/2005, Curt Arnold wrote:
>I can't stress how strongly that I believe these changes are bad and will
>unnecessarily cause some users of 1.2 to stay with log4j 1.2 or encounter
>broken behavior during the migration. I was disappointed that such
>significant changes were initially committed (back on the 18th) without
>any prior discussion or announcement. If I missed it, I apologize.
I understand. OK, to summarize:
1) The changes are compile-time backward compatible -- existing appenders
will compile just fine without change against 1.2 as well as 1.3.
2) The changes only affect programmatic calls to appenders maintained
outside the log4j project. If those appenders are invoked from log4j
configuration files, then they will work just fine and without change with
1.2 as well as 1.3.
3) Applications such as hivemind which configure their custom appenders
programmatically need to add one line to their code in order to invoke the
activateOptions() method. If they do that, they will be compatible with
both 1.2 and 1.3.
I've tried to explain to you the reasons for these changes over the phone.
Apparently, I was not very successful. :-)
>I think it is inappropriate to attempt to preemptively suppress a
>discussion. I think that I raised legitimate technical issues that should
>been discussed much earlier. I know that we disagree, I'd like to see
>what the rest of the list thinks.
You have raised a perfectly legitimate technical issue. I also happen to
think that it does not deserve the effort wasted discussing it. However,
you certainly have the right to raise the issue. If you'd like ask for a
vote on the subject, you do not need my permission to do so. It is your
right as a committer.
I'd just like to move forward with code that we can maintain on the long term.
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 25, 2005, at 1:22 PM, Ceki Gülcü wrote:
>
> Curt,
>
> While I appreciate your efforts in resolving the Gump failure with the
> Hivemind tests, what we have currently works just fine and is quite
> simple to understand. Could we please move on?
>
I can't stress how strongly that I believe these changes are bad and
will unnecessarily cause some users of 1.2 to stay with log4j 1.2 or
encounter broken behavior during the migration. I was disappointed
that such significant changes were initially committed (back on the
18th) without any prior discussion or announcement. If I missed it, I
apologize.
I think it is inappropriate to attempt to preemptively suppress a
discussion. I think that I raised legitimate technical issues that
should been discussed much earlier. I know that we disagree, I'd like
to see what the rest of the list thinks.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
Curt,
While I appreciate your efforts in resolving the Gump failure with the
Hivemind tests, what we have currently works just fine and is quite simple
to understand. Could we please move on?
At 08:03 PM 2/25/2005, Curt Arnold wrote:
>Seems we have found ourselves in a revert war.
>
>I really think we need to explain our positions and have a formal
>vote. My position is that we should not break compatibility with apps
>using or extending it in expected ways without discussion and if needed a
>formal vote. With the Gump breakage of Hivemind, I thought that I could
>proceed to restore 1.2 compatibility and then we could consider
>introducing potentially breaking changes.
>
>I have the following problems with the commits from last week and the
>current CVS HEAD that I think were adequately addressed in the CVS HEAD
>from last night.
>
>The new methods added to Appender will cause any independent
>implementation (not an extension of AppenderSkeleton) to fail to compile
>against 1.3. No such appender appears to exist within the projects built
>by Gump, but if the intent was to only allow instances of AppenderSkeleton
>to work with log4j, then addAppender should have taken AppenderSkeleton.
>
>The new methods added to Appender are not essential aspects of an Appender
>and are not needed for an independent implementation to work with
>log4j. An independent implementation of Appender could throw
>NotImplementedExceptions on those methods and everything would work
>perfectly as they are not currently with log4j (they are called within
>test cases, but that can be handled other ways).
>
>The new methods assumes a lifecycle of an appender being created in an
>inactive state, transitioning to active state and finally entering a
>closed state. Some appenders (VectorAppender, NullAppender) might never
>existing an in inactive state since they are immediately active on
>construction. Other appenders may have more complicated lifecycles, maybe
>entering a failure state or a dormant state where they drop database
>connections. The message dispatch logic has no need to know the internal
>state of an appender. If there develops an need to interrogate an
>appender about its internal state, then we should introduce distinct
>interfaces to support that and not just tack them on to Appender.
>
>activateOptions on AppenderSkeleton was renamed to activate and
>implementations of activateOptions within the log4j code base were
>renamed. AppenderSkeleton.activateOptions was reimplemented to call
>activate. Existing custom appenders were expected to implement
>activateOptions and may have derived from an intermediate class like
>WriterAppender that now implements activate. This would result in a call
>to AppenderSkeleton.activate() and a call to
>AppenderSkeleton.activateOptions() since activateOptions would invoke the
>custom appenders activation code. If code wants to work properly with
>existing custom appenders, then it should call activateOptions since that
>is the only call that works correctly with both internal and existing
>custom appenders, but it is deprecated and the JavaHelp tells you to call
>the method that may be unsafe with existing custom appenders.
>
>log4cxx (and likely) log4net attempt to mimic log4j's interfaces.
>These changes require them to either propagate these changes with the
>similar effects on their users or freeze on the 1.2 versions of these
>interfaces. I've been trying to bring log4cxx into tighter alignment with
>log4j since that makes it easier to port log4j code into log4cxx and would
>prefer that we not have to branch.
--
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: AppenderSkeleton.isActive, etc
Posted by Curt Arnold <ca...@apache.org>.
On Feb 25, 2005, at 7:59 AM, Ceki Gülcü wrote:
>
> Curt,
>
> I'd like to keep things simple and stupid. Imagining and implementing
> solutions for problems that do not exist makes the code hard to
> maintain. We already have a strategy for preserving backward
> compatibility which is both extremely simple and robust. More
> sophisticated solutions need to be maintained. They end up costing
> very dearly on the long run.
>
> Please, let us keep things simple. Log4j is not about proving how
> smart we are but about providing a reliable solution for our users --
> a solution which we can maintain on the long run.
>
>
Seems we have found ourselves in a revert war.
I really think we need to explain our positions and have a formal vote.
My position is that we should not break compatibility with apps using
or extending it in expected ways without discussion and if needed a
formal vote. With the Gump breakage of Hivemind, I thought that I
could proceed to restore 1.2 compatibility and then we could consider
introducing potentially breaking changes.
I have the following problems with the commits from last week and the
current CVS HEAD that I think were adequately addressed in the CVS HEAD
from last night.
The new methods added to Appender will cause any independent
implementation (not an extension of AppenderSkeleton) to fail to
compile against 1.3. No such appender appears to exist within the
projects built by Gump, but if the intent was to only allow instances
of AppenderSkeleton to work with log4j, then addAppender should have
taken AppenderSkeleton.
The new methods added to Appender are not essential aspects of an
Appender and are not needed for an independent implementation to work
with log4j. An independent implementation of Appender could throw
NotImplementedExceptions on those methods and everything would work
perfectly as they are not currently with log4j (they are called within
test cases, but that can be handled other ways).
The new methods assumes a lifecycle of an appender being created in an
inactive state, transitioning to active state and finally entering a
closed state. Some appenders (VectorAppender, NullAppender) might
never existing an in inactive state since they are immediately active
on construction. Other appenders may have more complicated lifecycles,
maybe entering a failure state or a dormant state where they drop
database connections. The message dispatch logic has no need to know
the internal state of an appender. If there develops an need to
interrogate an appender about its internal state, then we should
introduce distinct interfaces to support that and not just tack them on
to Appender.
activateOptions on AppenderSkeleton was renamed to activate and
implementations of activateOptions within the log4j code base were
renamed. AppenderSkeleton.activateOptions was reimplemented to call
activate. Existing custom appenders were expected to implement
activateOptions and may have derived from an intermediate class like
WriterAppender that now implements activate. This would result in a
call to AppenderSkeleton.activate() and a call to
AppenderSkeleton.activateOptions() since activateOptions would invoke
the custom appenders activation code. If code wants to work properly
with existing custom appenders, then it should call activateOptions
since that is the only call that works correctly with both internal and
existing custom appenders, but it is deprecated and the JavaHelp tells
you to call the method that may be unsafe with existing custom
appenders.
log4cxx (and likely) log4net attempt to mimic log4j's interfaces.
These changes require them to either propagate these changes with the
similar effects on their users or freeze on the 1.2 versions of these
interfaces. I've been trying to bring log4cxx into tighter alignment
with log4j since that makes it easier to port log4j code into log4cxx
and would prefer that we not have to branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: AppenderSkeleton.isActive, etc
Posted by Ceki Gülcü <ce...@qos.ch>.
Curt,
I'd like to keep things simple and stupid. Imagining and implementing
solutions for problems that do not exist makes the code hard to maintain.
We already have a strategy for preserving backward compatibility which is
both extremely simple and robust. More sophisticated solutions need to be
maintained. They end up costing very dearly on the long run.
Please, let us keep things simple. Log4j is not about proving how smart we
are but about providing a reliable solution for our users -- a solution
which we can maintain on the long run.
At 12:23 AM 2/25/2005, Curt Arnold wrote:
>I've committed some tweaks that I think should leave us in pretty good
>condition. I've modified the Gump descriptor for Cactus so that it should
>attempt to build against log4j 1.2 tonight which should allow us to tell
>if the recent breakage was due our recent changes.
>
>I've restored the test of isActive in doAppend and the problematic
>statements in AbstractAppenderTest. To make these work, I've added
>explicit constructors for AppenderSkeleton. Code that uses the default
>AppenderSkeleton constructor will be created with active = true which
>should result in behavior consistent with 1.2 for custom appenders. If a
>custom appender did not require activateOptions to be called, it will
>still work and if it did require a call to activateOptions and none was
>made, it will still fail in the same manner. All log4j classes (with the
>exception of Chainsaw classes) that derive from AppenderSkeleton call
>AppenderSkeleton(boolean isActive) which indicates whether they are ready
>to process events immediately after construction. I didn't change the
>chainsaw appenders due to the recent migration and they should work
>consistently with their previous behavior. I did not intend to change the
>appenders in the contribution sections and will revert them later this evening.
>
>In AbstractAppenderTest, I changed the type used in the tests from
>Appender to AppenderSkeleton. All the classes tested by
>AbstractAppenderTest are known to be inherited from AppenderSkeleton.
>The message dispatching code does not currently need to know whether an
>appender is active or closed, it just calls append and assumes that the
>appender does something appropriate with its state. I don't see any need
>at this time to break any (possibly hypothetical) implementations of
>Appender that don't extend AppenderSkeleton.
>
>I'm not sure about the duality of activate and activateOptions. It seems
>likely that there could be a problem when classes mix and match which
>methods they override. It may be better to change the implementations
>back to activateOptions and provide a final activate method that delegates
>to activateOptions. However, I did not work through the permutations.
--
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