up front summary: construction/destruction is not the concern of the CM,
but of the Container. The framework lifecycle interface associated with
destruction is Disposable.
> > <snip>
> >
> > So, from an elegance point of view, it makes perfect sense, for Avalon,
> > to provide aspect-oriented construction strategies *and* aspect-oriented
> > destruction strategies.
> +1000
This indeed makes perfect sense. Good analysis (including the <snip>ped
bits)!
> > Just like it's the component manager's concern to construct your
> > component the way the component was instructed to (depending on the
> > interfaces it implements), similarely, it should be the component
> > manager's concern (or some proxy slave, that's an implementation detail)
> > to dispose the component, depending on the disposing strategy that the
> > component implements.
> +1000 again
Here is where the doubts are. Is it the ComponentManagers concern to
construct / destruct your Component?
No, that's the Container. The ComponentManager is one of the
communication mechanisms between container and contained component,
aimed at providing components with references to other components.
How should a Container determine when a Component can be destructed?
What is the contract for this?
simple: when the Component has run through its lifecycle it can be
safely destructed.
Flow:
// in SomeContainer:
SomePool.start();
SomeCM.put( SomePool, SomePool.ROLE, SomePool.SOME_HINT );
// construction concern
component.compose( SomeCM );
component.initialize();
// program flow concern
component.start();
component.stop();
// destruction concern
component.dispose();
SomeCM = null; // GC's a bitch
SomePool.stop(); SomePool.dispose(); // release all
SomePool = null; // GC's a bitch
// in SomeComponent:
compose( ComponentManager cm )
{
if(cm.exists(SomePool.ROLE, SomePool.SOME_HINT)
m_pool = (Pool)ComponentManager.lookup(SomePool.ROLE,
SomePool.SOME_HINT);
}
initialize()
{
m_poolInstance = m_pool.getInstance();
}
start()
{
m_poolInstance.doStuff();
}
stop()
{
m_poolInstance.stopDoingStuff();
}
dispose()
{
m_pool.release(m_poolInstance);
}
Now for transparant pooling:
SomePerformantComponent.start();
// in SomeContainer:
SomeCM.put( SomePerformantComponent, SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT );
component.compose( SomeCM );
component.initialize();
component.start();
component.stop();
component.dispose();
SomeCM = null; // GC's a bitch
SomePerformantComponent.stop(); SomePerformantComponent.dispose();
SomePerformantComponent = null; // GC's a bitch
// in SomeComponent:
compose( ComponentManager cm )
{
if(cm.exists(SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT)
m_comp = (Pool)ComponentManager.lookup(
SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT);
}
initialize()
{
}
start()
{
m_comp.doStuff();
}
stop()
{
m_comp.stopDoingStuff();
}
dispose()
{
}
// in SomePerformantComponent:
/* implement pooling here */
Sure enough, the container has a tough job (especially as it might be
the one actually doing the pooling on a poolable component) , but the
result is a simple client API.
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
