> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> There are two approaches that have been approached:
>
> 1) Merge CM and Context
> 2) Use Context as CM and create a new ServiceManager
For this email I'll use the definitions used for Avalon 4. That is,
a Component provides a service. (URL != Component, for example).
Regarding Berin's two layers of factories - the instance-production
layer and the pool/thread-safe holder layer, I'll refer to the lower
layer as the Component Factory and the upper as the Component Handler.
> What was not addressed to my liking was that of how a Component
> was to know how to manage it's threadsafety concerns (whether one
> instance could be shared accross all threads or it needed to have
> a unique instance per thread).
The problem here is, I think, whether ThreadSafe, SingleThreaded and
Poolable captures every possible way of managing a component
with respect to its thread-safety. If they do, then the other problems
you list disappear.
If they do (and yes, I am in favor of the Poolable interface), then
I think we should:
1) Add a bool recycle () method to Poolable, removing it from
Recyclable. The method returns true upon successful recycling,
and false when not. Poolable extends SingleThreaded, for
graceful degradation where the CM can not create a pool.
2) Move the new Poolable to framework. If Poolable is as fundamental
as ThreadSafe, then it belongs in framework, not in Excalibur.
3) Stick with our current ComponentHandlers.
4) Add an optional "handler" attribute to the configuration, to
handle components that do not conform to Avalon standards.
For example:
<component role="..." class="my.ComponentImpl"
handler="my.ComponentHandler"/>
where my.ComponentHandler extends
org.apache.avalon.excalibur.component.ComponentHandler.
If none is specified, a handler is selected via marker interfaces.
5) Move org.apache.avalon.excalibur.component.ComponentHandler to
framework.
If not, then there is no guarantee that your component will work
with any implementation of Avalon.
BTW: Why this rush to get rid of marker interfaces? C# added custom
properties that could be attached to any object as a feature,
and here we are regressing, throwing away a great feature of Java -
namely that classes can contain metadata about themselves.
The only reason for getting rid of the marker interfaces is
if they become too many. But I think the set {SingleThreaded,
Poolable, ThreadSafe} covers 99% of the possible cases.
Allowing one to override the Component Handler class (and thus
the Component Factory) should be enough for the remaining 1%.
> Moving on to the Context ~ ComponentManager discussion. I must
> admit that there are
> some unique possibilities with this approach that cannot be done
> with the current
> ComponentManager architecture. By employing three or four layers
> of Context objects, you can easily represent a system fully.
You can easily represent a *request-response* system fully.
I would vote -1 on this, if I could. I'm trying to apply
Avalon patterns to games and simulation programming, and
while I could possibly map the layers you list to my application
it would be quite forced and far from optimal.
> However, if we are to access Components through this approach,
Berin, by "access" I suppose you are talking about the upper
layer of factories, the Component Handlers. I think we're really
messing up the contracts here. Basically, we access components
through a ComponentManager.
> While this leads to great flexibility, and the ability to alter
> the specific component
> based on the Context information
Is this not exactly what a ComponentSelector does?
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
