avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Excalibur service package
Date Sun, 03 Mar 2002 20:14:38 GMT

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Sunday, 03 March, 2002 19:36
> To: Avalon Developers List
> Subject: RE: Excalibur service package
> > From: Stephen McConnell [mailto:mcconnell@osm.net]
> >
> >       I would prefer an approach
> >       where the service manager implementation could locate a pool
> >       provider (handler) based on the type of object that is returned.
> Impossible. Consider a component, my.ComponentImpl, that implements
> my.Component and is pooled.
> Now consider the two roles my.Component/B and my.Component/A.
> Since the two roles have different configurations they are not equivalent.

I'm not providing support for configuration relative to roles.  The
implementation is based on the Phoenix notion of roles where a role is a
name that is used by a component when invoking lookup on a manager.  The
loader's responsibility here is to associate the service under the supplied
role name.  I'm using Phoenix notion of roles because (a) it's well
documented, (b) works with lots of existing blocks I have - and ensures
that I can switch between ServiceLoader and Phoenix deployment without
concern, and (c) is "Component" independent.

> When you get a my.ComponentImpl back you have to put it in the right pool,
> but the type information is not enough.

I also have reservations about the type approach because it would restrict
managers to the set of possible pools and would not enable pools that return
mixed types.

Ignoring the question of role oriented configuration for a moment, you end
with the requirement for either (a) the pooled object to be able to identity
source pool - which is undesirable, or (b) forcing the manager to maintain
usage state (i.e. for every lookup - create a usage object that associated
the pool and the object so that on release the object can be released to the
correct pool).  I have played a little with the second option - suffice to
that it is feasible to do this as an internal implementation detail of a
generated manager.

Cheers, Steve.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message