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

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