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

Hi Mauro,

Mauro Talevi wrote:

> Jörg Schaible wrote:
[snip]
>> 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.

Well, this more or less exposes the complete problem: We don't have a spec
for the LC. A simple document like it was available for Avalon. Clean and
simple. Each dev knew exactly what he/she had to expect from the container
and what was in the developers responsibility.

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

IMHO we can live with any solution - as long as it is explicitly defined.
Obviously we had until now different positions about the LC which led to
different requirements and implementations ...

- Jörg


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

    http://xircles.codehaus.org/manage_email