avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 20:28:45 GMT
> Therefore, I suggest we come together on how we lookup and use our
> components. 

of course, I personally feel this discussion belongs on avalon-dev and
all interested should join us here =)

> Which raises two very good points.  How should we handle the CM
> interface,
> and do we need exceptions?
> 
> As a result, I would like to go back to grass roots, with a couple
> modifications.

I love it when a plan comes together =)

> Here is the interface for the CM:
> 
> interface ComponentManager
> {
>     Object lookup(String role);
>     Object lookup(String role, Object hint);
>     boolean exists(String role);
>     boolean exists(String role, Object hint);
> }

+1.

> 1) We return Object instead of Component.  This merges the lessons
> learned from
>    the ServiceManager discussions about accessing legacy components that
> are not
>    able to emplement the Component interface.

a "duh" for me by now =)

> 2) We remove all *declared* exceptions.  If there is something wrong, it
> is more
>    appropriate to throw a RuntimeException.

The removal of ComponentException essentially says that the only
exception ever to occur during lookup is the requested component not
being there. If there are others, all this falls to pieces. I don't
think there are though.

> 3) We add an additional lookup and hasComponent method (role, hint
> combination).

While not really neccesary in practice (you can tweak the role to
include whatever 'hint' you have), it is clean, and as long as it is
optional, it won't hurt me ;)

> 4) We remove the release() method altogether.

hurray!

> What will require some convincing--esp. to the Cocoon crew is the
> removal of
> the release() method.  To that end, read the last section.

snipping hideously complex explanation...summarising very briefly:

***pooling should not be the concern of the ComponentManager***

Pooling *can be* the concern of the container. Or it can be the
responsibility of the client application, or of a third-party API (ie
JDBC driver with built-in pooling).

If you remove pooling (or less specific perfomance-related) concerns
from the ComponentManager, release() is unneccessary.

Need pooling? -->

if( cm.exists( MyPool.ROLE ) )
{
	myObj = cm.lookup( MyPool.ROLE ).getInstance();
	myObj.doStuff();
	myObj.release();
}

there can only be discussion when you make pooling the concern of the
CM. I think this is improper SoC.

one more thing:

Why is a role a string?
-----------------------
Because strings are easy for humans.

consider:

interface ComponentManager
{
    Object lookup(Role role);
    boolean exists(role role);
}

or even:

interface ComponentManager
{
    Object lookup(Object role);
    boolean exists(Object role);
}

and what we have is basically a read-only HashMap with a specific
contract and no unneccessary "convenience" methods.

regards,

- Leo



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message