logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Life cyle and appender
Date Tue, 20 May 2014 03:33:07 GMT

Yes, but it will be a bit of a chore. The following classes extend AbstractFilterable.

1. AbstractConfiguration already has start and stop methods so should implement LifeCycle.
However, it also uses a setup method which isn’t part of Lifecycle but that should be OK
the way it is.
2. LoggerConfig - It currently doesn’t have anything equivalent to the LifeCycle methods
but they probably will come in handy.  AbstractConfiguration is already calling startFilter
and stopFilter so the start and stop methods could be called at the same time.
3. AppenderControl - This is the one I see an issue with. It is created when an appender is
added to a LoggerConfig as a reference.  It probably should implement LifeCycle as it calls
startFilter in the constructor but it doesn’t look like it calls stopFilter anywhere. I
guess the start and stop should be called in the addAppender and removeAppender methods.

Ralph

On May 19, 2014, at 6:39 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> On Mon, May 19, 2014 at 9:34 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> Let's start with a specific case: AbstractAppender clearly has life cycle features (start/stop)
but it subclasses AbstractFilterable.
> 
> Would it be correct for AbstractFilterable to be a life cycle and subclass AbstractLifeCycle?
> 
> Let me clarify that AbstractAppender implements Appender which extends LifeCycle, so
the formal definition is OK: An AbstractAppender is indeed a LifeCycle.
> 
> I am looking to answer if we can make AbstractFilterable extend AbstractLifeCycle to
inherit the pre-canned life cycle behavior.
> 
> Gary
> 
> Gary
> 
> 
> On Mon, May 19, 2014 at 9:29 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> I think there is a Jira about that.  I have a feeling that there are more classes that
should use LifeCycle but don’t and do their initialization a little differently, but it
would require going and looking through all the classes to determine that.
> 
> Ralph
> 
> On May 19, 2014, at 12:37 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
>> All:
>> 
>> I abstracted out the life cycle management code out of LoggerContext into it's own
abstract class and reused it in (now) subclasses that provided the same kind of functionality
(please see revision 1596001.)
>> 
>> The next question is: The AbstractAppender extends AbstractFilterable and also has
life cycle management features (isStarted()/isStopped()). If AbstractFilterable would extend
AbstractLifeCycle, then more classes would carry the state ivar. I did not do that because
it did not feel right without more consideration.
>> 
>> I know someone else had mentioned life cycle work as a to-do so here's a start in
a manner that is reused now in a few different places. 
>> 
>> Thoughts?
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


Mime
View raw message