Which ever way we go on this, let's get 2.1 out the door first. We have some nice new functionality for 2.1 already (JUL, IO streams). Once we fix our clock threading issue, I say we clean thing up and prepare 2.1.
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
