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: Would anyone be against simply copying the lifecycle standards from OSGi?
Date Sun, 14 Sep 2014 02:48:40 GMT
I think you are going to need something more concrete to convince me that emulating the OSGi
Lifecycle is necessary.

Ralph

On Sep 13, 2014, at 7:07 PM, Matt Sicker <boards@gmail.com> wrote:

> Having at least more than one boolean state will help with concurrency issues when starting/stopping
a thing. Using the OSGi life cycle means that all platforms can have sufficient life cycle
support for things that need to be managed as such. Spring may have only those three methods
as Ralph pointed out, but it also provides several more life cycle related interfaces for
more advanced life cycle behavior.
> 
> As a Log4j plugin developer, I want to be able to add and remove my plugins at runtime
(quite possibly after log4j-core et al. have already been started) in order to support OSGi
in a more complete fashion. If my plugins get reloaded by OSGi for instance, then Log4j will
have no idea what to do with the classes OSGi wants to unload (and most likely cause a memory
leak). Having a more well-defined plugin life cycle will help me to develop and debug my own
plugins.
> 
> Also, as a Log4j customer, I want to be able to be able to start and stop plugins at
runtime through JMX. This would work well with the failover appender as well as provide new
opportunities for programmatic configuration.
> 
> On 13 September 2014 20:58, Gary Gregory <garydgregory@gmail.com> wrote:
> Well... this is an interesting topic.
> 
> At work and here at Log4j, and other personal projects I've introduced life cycle classes
of different types.
> 
> I've specifically not reused other frameworks for a simple reason, I was not going to
pretend to co-exist and jump through hoops to follow the proper semantics of a 3rd party f/w.
Call it NIH, call it YAGNI, call it what you will, that was my thought. The log4j LC f/w is
a Log4j Core private thing.
> 
> Now, I do understand that there are well thought out LC bits out there. OSGi is clearly
high on the do it all list especially considering that it has been implemented many times
(Eclipse is one example).
> 
> So the question for me is: Is it worth redoing/changing the Log4j LC? 
> 
> At one extreme I see dumping as much of our bits as possible and using OSGi interfaces/classes.
Could we get to the point where we could integrate "perfectly" and in the most OSGi-native
manner with an OSGi container, sure. I bet we already do since we have an Activator.
> 
> At the other extreme, I could see just adding the missing states and renaming the ones
we have to match OSGi concepts.
> 
> So, what are we trying to do here? What are our "user stories"? "As a Log4j developer,
I want..."; "As a Log4j 3rd party plugin developer, I want..."; "As a Log4j customer, I want..."
> 
> Let's start with those, shall we?
> 
> :-)
> 
> Gary
> 
> 
> On Sat, Sep 13, 2014 at 4:45 PM, Matt Sicker <boards@gmail.com> wrote:
> They're the most flexible. Quick overview of the life cycle in OSGi:
> 
> installed -> resolved -> (starting) -> active -> (stopping) resolved ->
uninstalled
> 
> Installed is the initial state. Resolved is when all its dependencies have been fulfilled.
During the starting state, if there is an error, then it goes back to resolved. Active for
while it's, well, active. Stopping puts the thing back into resolved. Then, if you go from
resolved to uninstalled, this means that it's no longer available for use (and the only reason
you'd find something in this state for very long is due to a memory leak).
> 
> Any objections? This would make our LifeCycle interface more compatible with OSGi while
providing a well-understood standard for the life cycle of plugin-type objects.
> 
> -- 
> Matt Sicker <boards@gmail.com>
> 
> 
> 
> -- 
> 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
> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>


Mime
View raw message