cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Mon, 10 Jun 2002 04:56:14 GMT
> From: Vadim Gritsenko [] 
> Shouldn't some standard (default, etc) Manager will be available?

And what, pray tell, would it look like?  The COmponentManger as it is
defined is a lookup mechanism.  Nothing more.  The ComponentSelector
pattern was designed to allow multiple choices for the same component
type based on a hint.

The thing is that many times all you need is Role/purpose or Role/Name
combo for that.  If all you need is that, then the new CM interface
will help you out.

It's like the difference between a regular connection and an SSL
connection.  Sometimes you need to choose programatically.  In those
cases, all we need to do is lookup(ConnectionManager.ROLE, "SSL"),
which is good enough.

It is when you require something more fine grained than a *per thread*
granularity.  In other words, if there is a good chance that there are
several component instances in any given thread of execution, then
something needs to change.  Either it needs a more fine grained manager,
or the components themselves need to change.

> I really not exactly understand necessity of different 
> managers, or, let's put it this way, absence of some 
> standard/default manager interface. I got the part that 
> lookup and component lifecycle will be implemented by two 
> different entities, not the one component manager (as of now) 
> - and I have no issues with this.
> But I don't get why you force different manager for every 
> different component. Then, you won't be free anymore to 
> switch between different component implementations (or change 
> implementation) - you will break XXXXXManager interface which 
> depends on implementation of the component.

Look, for many components (more the rule than the exception)
you won't need a XXXXManager.  If the interface is intelligently
designed, then there is no reason for an XXXXManager.  In Cocoon's
case, it needs it to provide backwards compatibility while it
improves its component model.

Truthfully the component in question is the XXXXManager.  The
actual instance returned is more an artifact of the processing.
The XXXXManager allows more intelligent treatment of the types
of information/components/etc. that it manages than a generic
interface or solution could ever do.

> To illustrate the point: manager of ThreadSafe component 
> won't have release(), manager of non-disposable component 
> also won't have release(). If you ever decide that your 
> component must be disposable or it must be poolable you have 
> to change XXXXXManager interface, and, as a result, rewrite 
> *all* the clients of this interface.

To illustrate my point: if there is a possibility that the
XXXXManager has pooled objects, then you have a choice:

* Hide the pooling mechanism into the normal use of the artifact
  (ContentHandler, XMLSource, JDBC Connection)
* Or explicitly force the client to remember to return the pooled

Both have their challenges.  I prefer to hide the pooling mechanism
as much as possible--but that is my preference.  It would be
ludicrous to build a new Manager for each lifestyle (creational

The point is that not every type of component, or every approach
works for all people.  We want to move that choice, that concern,
into the hands of the component developers and not into the lookup
mechanism.  Otherwise the normal use code of working with a
ComponentManager becomes more complicated than necessary--for the
benefit of only a few components.

> What about cast to XXXXXManager?
>   MyManager mm = (MyManager)cm.lookup("role");
> While removing one cast another was added.

Not necessarily.  When we resolve components, we have to cast them.
doesn't change.  But compare that with a ComponentSelector (as we have
them now):

ComponentSelector selector = (ComponentSelector)
        cm.lookup(DataSourceComponent.ROLE + "Selector");

DataSourceComponent dsc = (DataSourceComponent)"secondDB");
Connection conn = dsc.getConnection();


Compare that to the new and improved way:

DataSourceComponent dsc = (DataSourceComponent)
        cm.lookup(DataSourceCompoennt.ROLE, "secondDB");

Connection conn = dsc.getConnection();

It saves both an additional lookup, and an additional cast.

To unsubscribe, e-mail:
For additional commands, email:

View raw message