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]>

Reply via email to