Re: [picocontainer-dev] While looking at the streamlining of NanoWar ...

Yep, you point out much of the complications we have by even  
attempting lifecycle.

Indeed, in that new LifecycleState (should probably be called  
LifecycleStateModel or similar), there is a starting() but no  
started(), and in DPC when doing start/stop/dispose there's no try/ 
finally.  There's also no contract with respect to one component's  
lifecycle failure when some have already entered into that state.  Its  
all a bit unspecified really :-(

While coding the latest patch (a few minutes ago), I noticed that the  
state probebly belongs with the StoreWrapper as the same things were  
happening to it at the same time.  Thus its less to do with the  
container (as you say) and more to do with the components the  
container manages (even if on thread local).

- Paul

On May 25, 2008, at 11:34 PM, Jörg Schaible wrote:

> Hai Paul,
>
> Paul Hammant wrote:
>> ... and given my task is to replace 'one container per
>> session and one
>> container per request' with three 'static' containers + some
>> threadlocal store magic ...
>>
>> ... a problem is that start()/stop()/dispose() will have to be
>> rethought for session and request scoped components.
>>
>> Do people use lifecycle for session or request scoped components?
>>
>> - I'm guessing the answer is yes, but what for ?
>>
>> What if these session and request containers, did not have state
>> themselves, but merely cascaded start/stop/dispose to the components
>> they manage ?  i.e. StatelessPicoContainer (or better name)
>
> finally, you've hit the same problems that I had some years ago with  
> Pico 1.x. Remember my fight about the LC strategy <g>
>
> Yes, I my "session" scoped containers had own lifecycle, but I did  
> not linked them necessarily with the LC of the parent container.  
> Typically the root container for the scope was referencing the  
> parent container using its ctor, while children of that request root  
> container were made with makeChildContainer. LC was the subtile  
> difference. Nevertheless the LC problem falls back on the adapter.  
> If the container has been started already, should a new instance be  
> started also (e.g. created for a new thread or simply because the  
> comonent is intentially not cached)? What should happen if the  
> container stops? Only stop the components that have been started?  
> Can a component be disposed that has not been started?
>
> Perhaps these are the wrong questions, we should concentrate on the  
> component - not the container. If we try to support individual LC- 
> aware components, the component itself should not care about its  
> "scope", i.e. the component should be usable from a cached, non- 
> cached or scoped container/component adapter. The component should  
> not have to take care whether the container created multiple  
> instances of the component or not. But what is the assured contract  
> regarding the LC for the component? Is it guaranteed that start/stop  
> is always called in pairs? Is it guaranteed that disposed is called  
> at the end of its LC? Can disposed be called without the component  
> being started or stopped? On what can the component rely on?
>
> After answering this questions, the functionality of the container  
> should be clear - although it might be hard to achieve. In default  
> Pico mode this is easy - all components are cached and the point in  
> time calling the LC methods is well defined. But things are getting  
> complicated regarding LC if the container's components no longer act  
> like singletons.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email