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 <[email protected]> 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 <[email protected]> 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 <[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 > 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 <[email protected]>
