Stephen McConnell wrote:
>
> The CL->CM->C snippet from Leo:
> -------------------------------
>
>
> Use the ComponentLocator to get the ComponentManager.
> Use the ComponentManager to get the Component.
> Once you are done, put the Component back into the ComponentManager.
>
> interface ComponentLocator {
> public Object lookup ();
> }
>
> interface ComponentManager {
> public Object getInstance ();
> public void release (Object o);
> }
>
> I think this is in line with EJB (XXXHome interface) but with an
> explicit release(), as we have not found some kind of release()
> unneccesary.
This is completely consistent with the A5 approach. What I like is the
fact that Leo is suggesting the pooled resource management (refered to
above as ComponentManager) can be formalized at the framework level.
Ignoring the name for a moment - the important thing is that this is
not an interface that would be exposed by any lifecycle phases - it is
simply a utility interface which would enable component implementations
that want to explicity release object to do so in a consistent manner.
The second point concerns the name - and this is a two sided coin.
Calling it ComponentManager is consistent!
------------------------------------------
Bacause A4 component manager interface defines the this functionality.
The A4->A5 difference is that the functionality concerning pooled
object management can be handled either:
- implicitly by the container
- explicity by the component (using the proposed interface)
Secondly, maintaining the ComponentManager interface means less
changes to code that is migrated from A4 to A5 because the semantics
defined by interface are functionaly consitent with the current
A4 interface of the same name (with the only differences being that
it is resolved by the client using a locator instead of directly
via compose, secondly, lookup is repaced by getInstance (which is
more consistent in the context of a pool) and the lastly, the
absence of the Component marker interface on release.
Calling it ComponentManger is confusing!
----------------------------------------
There is a lot legacy documentation that we will have to deal with
and there is legecy mind-set that associated a ComponentManager with
the framework Composable.compose( ComponentManager ) pattern. Perhaps
a better name for what Leo is proposing is ComponentPool.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
