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 <garydgreg...@gmail.com> wrote: > On Mon, May 19, 2014 at 9:34 PM, Gary Gregory <garydgreg...@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.go...@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 <garydgreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
