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 <[email protected]> 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 <[email protected]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
