> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 15 February, 2002 12:11
> To: Avalon Developers List
> Subject: RE: [VOTE] RE: ComponentManager interface
>
>
>
>
> > 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
> > don't find this a convincing argument in terms of the
> > for arbitrary release - but I functionality of the framework. The
> > reason why is that if you declare release on ServiceManager,
> > you are implying that an implementation may support this ([and]
> > 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.
Correction - Excalibur has ThreadSafe, Poolable and SingleThreaded.
Framework does not. We are discussing the semantics of a core set of
interfaces and default implementations on which higher level components
can be constructed. The current ComponetManager has no notion of the
the types of objects it provides and the default implementation does
nothing in response to the remove invocation. Keep in mind that an
implementation of ServiceManager should not be seeking to supply
functionality beyond the basic contract that its interface provides.
This is a *really* important point. What you are describing is a
requirement for an interface that does more that CM/SM. That ok to
have that requirement, but its not ok force that requirement at the
framework level of abstraction. What you need is a new abstraction
level.
> 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?
Its academic because ThreadSafe, Poolable, SingleThreaded are unknown
concepts at the level of the framework. It doesn't matter if your
assertion is right or wrong - it simply as assertion that isn't within
the scope of the framework abstraction.
> If it isn't so, then what you say makes sense.
It isn't so, therefor, what I 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.
What you are saying is that for any "lookup" there must be a
parallel "return". I have a set of sources here in front of me
that collectively represent over 100 instance of lookup invocations
without a single return invocation. There is one case where is
likely that a recycling policy will be introduced. In that case the
implementation will be aware of the manager policy that is applicable
concerning object decommissioning and in that case it will follow
that policy.
> I would say that any implementation is either ThreadSafe, Poolable or
> SingleThreaded.
A reasonable assumption.
> The implementation is either ThreadSafe or not - there are formal
> ways to define thread safety, so just apply those here.
Cannot do.
These are abstractions above the framework. I.e. from a computational
point of view - the framework does not have any notion of the concepts
of thread safety - these concepts are equivalent to Frobnicatable.
The way to deal with this is to define a new interface at an abstraction
layer that knows about these things.
> 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.
Which also implies the introduction of explicit release on components that
don't need to be released because the managers handle disposal. I complete
understand the rational your putting forward - I just disagree on the
"place" where that rational should be expressed. Everything you have
said so far says that these issues should be express in an
ExcaliburComponentManager.
> 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.
It is fixed if we come to a conclusion on this process - enabling
retraction of the expose of Component on the ComponenManager interface.
Right now we have ComponentManager - i.e. its not fixed.
> 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
That's a workaround on the current CompoonentManager. The solution
is to replace ComponentManager.
> I have yet to see a use case that could not be solved within the
> Avalon framework as it is,
You outline a case above. An ORB is a class - it does not implement
any interfaces. You said that the solution (workaround) is to use
ExcaliburCoponentManager instead of the framework ComponentManager.
You describing a case that cannot be managed with the Avalon
framework. But this is not the issue, the issue is handling the
balance between framework integrity and framework usability. My
assertion is the integrity is correctly expressed under a manager
that does not expose "remove", and that generic manager in which
every client invokes remove is simply a level of abstract above
the framework. That means declaring a module and interfaces that
leverage framework interfaces as the building blocks.
> without throwing out many of the contracts
> that made Avalon so good.
Think of it as "respecting" the contracts that have made Avalon
so good and recognising when their are problems to be solved.
> 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.
Absolutely ... YES, totally agree. But provide the
rationalisation for the following extract form
DefaultComponentManager:
/**
* Release component.
*
* @param component the component
*/
public void release( final Component component )
{
// if the ComponentManager handled pooling, it would be
// returned to the pool here.
}
This is simply evidence of the fact that there is a notion expressed
in the current ComponentManager interface that cannot be implemented
at the framework level of abstraction.
The bottom line question is the following:
==========================================
*****
Does the notion of "service(...)" (was "compose(...)") from
Serviceable (was Composable) imply (a) the requirement that a
client narrows the returned manager to a release-aware manager,
or (b) modification of the level of abstraction of Serviceable
such that it applies a object the is release aware, or (d)
redefinition of ServiceManager such that it reflects an
abstraction above the current ServiceManager in that it is
release aware.
******
If we can focus our attention to the above question - we may perhaps
come up with a resolution. If we attempt to mix abstraction layers we
are only cheating ourselves because we are not facing up to the real
issues. Please note that I completely recognise, understand and
appreciate the utility of "release" on the ServiceManager interface.
I also recognise, understand and appreciate that we have an
abstraction issue to resolve - i.e. there are demands for this
functionality and the functionality cannot be managed with any
integrity at the framework level - which means definition of
"something" that meets the requested abstraction, based on a set of
framework components.
Until tomorow, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
