Well, I think uninstalled would only apply when using OSGi unless we implemented our own ClassLoaders that could unload code. Otherwise, we'd have different semantics for what uninstalled means.
On 9 October 2014 08:58, Gary Gregory <[email protected]> wrote: > If we were to use OSGi states, one thing that we would need to make sure > works for us is: "An UNINSTALLED bundle can not be set to another state; > it is a zombie and can only be reached because references are kept > somewhere." [1] > > Gary > > [1] http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html > > On Sun, Sep 14, 2014 at 1:01 AM, Matt Sicker <[email protected]> wrote: > >> Sounds good to me. >> >> On 13 September 2014 23:53, Gary Gregory <[email protected]> wrote: >> >>> 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 >>> >> >> >> >> -- >> 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 > -- Matt Sicker <[email protected]>
