> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> Sent: den 15 februari 2002 14:27
> To: Avalon Developers List
> Subject: RE: [VOTE] RE: ComponentManager interface
>
>
>
>
> > -----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.
I believe we went through this and found some concensus that these
three should be moved to framework as they represent general metadata
about components that all implementations of the framework should
be aware of, although they may not support those specified as optional
(Poolable, for example, should be optional).
> 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.
Wrong. Returning components or service interfaces when you are done with
them is just as fundamental as obtaining them.
> > 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.
Which is wrong again. All metadata about components belong in framework,
as every component should be usable in every component manager.
>
> > If it isn't so, then what you say makes sense.
>
> It isn't so, therefor, what I say makes sense :-)
No. :-)
> > 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".
Yes. And I am also saying that a single lookup()/release() pair is
sufficient.
> 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.
What implementation? The implementation of the sources, or the code doing
the lookups?
If it is the code doing the lookups, then that is wrong.
> > 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.
No. These are metadata about objects and the three of them completely
covers any possible lifecycle for a component.
> 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.
Yes. That is the only way to switch from a ThreadSafe to a Poolable
implementation
of a component without having to change the code using the component.
> 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.
It can be done with a wrapper, autogenerated by a code generator.
- Configurable via Avalon's Configuration, as an extra plus.
> 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 this is where I disagree - not having remove requires the client
to know about implementation details such as whether a component
is thread safe or not, whether it is pooled or not.
*** It is utter and complete madness. ***
*** Plus, Stephen, consider MY HEALTH: ***
"OK guys, since I have written a pooled version of the previously
single-threaded component, you have to change every place in the code
where you use it. Make sure to release it properly. I'll
get a ThreadSafe version up soon, so get ready to change back.
Oh, and I hope you all have a nice weekend. See you Monday.
/LS"
I do *not* want to end up on an episode of "When Developers Attack".
Nor do I want to end up on an episode of "When Bosses Attack".
("What do you mean we can not provide a pooled version for this customer?")
> 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.
> }
Given that the lifecycle of each component is either SingleThreaded,
Poolable, or ThreadSafe, we provide metadata about this in the form
of marker interfaces.
As with all metadata, some of it *must* be honored, while other
data are optional and serves merely as a hint to the manager of that
component.
Thus, if a CM implementation, while honoring the contracts imposed via the
must-honor metadata, can leave a method empty, it is allowed to do so.
One could argue that this would lead to loads of empty methods, given the
amount of metadata, but in fact only one is necessary - release().
> 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.
> ******
(c) I don't quite understand the other options, but I want a release()
method in SM.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
