> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> I'm not convinced that it isn't a client concern. The contract between
> the client and the provider of the service is that it is the clients
> responsibility to check something back in. Ok, I understand that
> it is more
> convenient in a highly pooled environment for arbitrary release - but I
> don't find this a convincing argument in terms of the functionality of the
> framework. The reason why is that if you declare release on
> ServiceManager,
> you are implying that an implementation may support this (a generally
> speaking "may" is a very bad word).
Stephen,
I believe that release() should be in the Manager interface, and that all
components should be released by the client.
The reasoning is as follows:
At the moment we have ThreadSafe, Poolable and SingleThreaded components,
where SingleThreaded really means SingleUse.
Now, consider the set {ThreadSafe, Poolable, SingleThreaded}. Does it
contain every possible component? That is, is it impossible for a component
to be neither ThreadSafe, nor Poolable, nor SingleThreaded?
If it isn't so, then what you say makes sense. Because then we may not just
have
a release() method, but there may be components that are Frobnicatable, and
we
would need to add a deFrobnicate() method to dispose of them.
I would say that any implementation is either ThreadSafe, Poolable or
SingleThreaded.
The implementation is either ThreadSafe or not - there are formal ways to
define
thread safety, so just apply those here. For non-thread safe
implementations,
the component can either be reused or not. (ThreadSafe impl must be reusable
by
definition.)
Thus, a release() method is sufficient, and all components can be treated
the same,
irrespective of their thread safety.
Requiring the client to be aware of implementation details such as whether
the component is a thread safe singleton or pooled is a huge leap backwards,
and I would be -1 on any such change.
I believe someone was trying to use the CM interface to get CORBA objects,
finding it impossible since a CORBA remote reference, or ORB, doesn't
implement
Component. This is fixed with the change from Component -> Object.
Lifecycle management of CORBA references should be done by
1) subclassing ECM and make it sensistive to CORBA interfaces
2) allowing CM implementations to be pluggable a' la Cocoon's
parent-component-manager
I have yet to see a use case that could not be solved within the
Avalon framework as it is, without throwing out many of the contracts
that made Avalon so good. Yes, those contracts means that there are
requirements on the components you use with Avalon, but if a framework
is to have any use at all, it has to put demands on the code written
for it.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
