> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> 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
artifact
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
policy).
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.
That
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)
selector.select("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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
