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

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

Joerg,

I tend to see the lifecycle applied to the container as simply a facade 
for the components' lifecycle, eg 'starting' the container means 
starting its components.  In most cases, this satisfies the lifecycle 
use case.  True there are some (relatively specific) use cases for which 
this approach may be inadequate or too rough-grained.  But in these 
cases the user can simply retrieve the individual components and start 
them directly - without invoking the containers start method.

ATM - DPC assumes a fail-fast approach:  if any startable component 
fails the container will not start.   True - we can improve this use 
case and handle better the stopping of the components already started 
(quite a borderline use case that of components which outlive the 
container, eg network sockets opened and such) but it does not take away 
the fact that LC is already IMO component-centric (although linguistical 
interpretations may vary :-).
But the LC state of the container only makes if all the components are 
in a consistent state - eg started or stopped.  Your point about the 
non-cached components is a valid one, but then those components' LC 
should be handled individually as mentioned above.

Cheers





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

    http://xircles.codehaus.org/manage_email