You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/16 10:10:10 UTC
Son of ComponentManager
Folks,
There are now even more things being proposed for this. What ever you
do could you remember that there are a group of people who have a real
use for an Object form of ComponentManager today. Could you PLEASE
consider something that delivers what they want as simple as ...
public void xxxxxxx(XxxxxxManager cm) throws XxxxxxException {
mSomething = (Something) cm.lookup(SOME_STRING); // cast from
Object to Something
}
... Inspired by ...
public void compose(ComponentManager cm) throws ComponentException {
mSomething = (Something) cm.lookup(SOME_STRING); // cast from
Component to Something
}
I don't care if you retrofit Tokens, Maps, Policies, Rules, Hints as
additional concepts. I don't care if you do this by evolving interfaces
or by extension. I do care that it is simple and what the user wanted (tm).
Tell me if you are not going to deliver the 'Object lookup(String)
throws..' method and I'll stop moaning in these threads.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
There is no need to be so faceteous.
- Paul
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Leo:
>>
>>>And then you can use om.lookup for objects and components.
>>>Does this solve your immediate needs? That is, getting
>>>something working NOW, with not too much crap for future
>>>cleanups?
>>>
>>Absolutely not!!!!!
>>
>
>Stephen,
>
>well, you were not asked. Whether this fits with your idea of what should be
>is utterly irrelevant.
>
>Paul needs something ***now*** as in "right this second".
>
>I have the impression that his development is ***blocked*** until he can
>get non-Component classes out of a CM. If I am wrong, well - ignore the
>solution and we'll hack away at the next-generation CM.
>
>I am very well aware that the solution I proposed is very temporary,
>and not a substitute at all for a proper solution that will be in
>Avalon 5. Or 4.2. Or whatever.
>
>But:
>
> - It allows him to proceed with his project ***NOW***.
> - It allows him to do what he wants with Avalon 4 ***NOW***.
> - It can easily be upgraded to Avalon 5, or whenever the new interfaces
> become available.
>
>Whether it sucks in an architectural way is not even a consideration.
>
> ****** I know it does. ********
>
>>Please go back and read the proposal.
>>http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06099.html
>>
>
>I am well aware of the proposal, and since I consider it madness to
>expect the client to be aware of poolable/threadsafe I am -1 on it.
>
>The proposal, as given, is *more* than just a jettisoning of the Component
>interface. If your proposal had just been "Component -> Object for
>ServiceManager,
>otherwise same contract as CM", I would have been +1 on it. But it is *much*
>more.
>It shifts responsibilities around in ways that I consider unacceptable.
>
>If SM replaces CM in Avalon5, *all* code written for Avalon4 will break. Not
>just
>in a way that can be solved with a search and replace, but the code has to
>be
>re-engineered to detect poolable components, or do away with those.
>
>>The solution is already there - you may want to sit around until
>>
>summertime
>
>>contemplating the meaning of life but some of us have more pressing
>>
>agendas.
>
>Stephen, I am well aware of pressing agendas. That is why I sent that
>solution
>to Paul. There is not enough time to get anything into Avalon proper.
>The solution I gave is precisely for pressing agendas. If development
>is blocked due to an API constraint, then a way must be found around that
>constraint so development can proceed. Then, when the API has changed to
>something that can be used without the kludges added before, remove kludges.
>
>THAT is what my solution to Paul is about.
>
>Every second, Paul & co. are basically idling. If they can get a kludge in
>that allows them to proceed, is that not preferable to idling even if it
>means that some changes will have to be made to the code afterwards -
>changes that can easily be contained to a single abstract base class?
>
>/LS
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Minor correction to prev. message.
The defintion fo Resolvable should be the following:
interface Resolvable
{
public void resolve( ServiceResolver resolver ) throws
ServiceException;
}
Steve.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Sunday, 17 February, 2002 18:05
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> Leo Sutic wrote:
> [snip]
>
> > The question is then: Given a ServiceResolver that provides a
> > unified way of obtaining services irrespective of whether they are
> > pooled or not, what use is there for ServiceManager?
>
> Because an implementation of ServiceManager is not polluted with
> operations against which it has not semantics. Specifically, all
> operations defined under ServiceManager are well defined - no ambiguity.
> ServiceResolver captures semantics of pooled services without ambiguity.
> So the up-side is that the interfaces are cleaner and the object mode is
> consistent. The down-side is that a lifecycle pipeline needs to be aware
> of the additional ServiceResolver interface. For me the up-side
> significantly outweighs the downside.
>
> Here is consolidation of the interfaces based on a logical extrapolation
> of the conclusions reached under this thread:
>
> interface Serviceable
> {
> public void service( ServiceManager manager ) throws
> ServiceException;
> }
>
> interface ServiceManager
> {
> Object lookup( String role );
> boolean hasService( String role );
> }
>
> interface ServiceSelector
> {
> Object select( Object policy );
> boolean isSelectable( Object policy );
> }
>
> interface Resolvable extends Serviceable{};
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object token );
> void release( Object object );
> void releaseAll( Object token );
> }
>
> interface PooledSelector extends ServiceSelector
> {
> Object select( Object token, Object policy );
> }
>
> Over to you.
> Cheers, Steve.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Antti Koivunen wrote:
> Leo,
>
> Leo Sutic wrote:
> > Before I go and vote for this one, I would also like to hear more
> > about Peter's release-less version. If that one works, we could have:
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role, Object policy );
> > }
>
> I'm afraid this would only work for thread-safe services ...
I'd better add "...without using intermediate proxy/delegate objects".
It should be possible to use dynamic proxies to achieve this, but there
would be a small performance hit on every operation. Things could also
get quite complex on the ServiceManager/container side.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
>
> interface SeviceResolver
> {
> Object lookup( String role );
> Object lookup( String role, Object policy );
> void release( Object object );
> }
Yes. And call that ServiceManager.
I typed up a proposal in my last email, but yes. The above
is what I want. (It's *easy*.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Leo,
Leo Sutic wrote:
>
<skip/>
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role );
> Object lookup( Object token, String role );
>
> Object lookup( String role, Object policy );
> Object lookup( Object token, String role, Object policy );
>
> void release( Object object );
> void releaseAll( Object token );
> }
>
> where the policy object is passed along to the selector if present?
This is a little better, but the following might be easier to implement
efficiently:
interface ServiceResolver
{
Object lookup( Token token, String role );
Object lookup( Token token, String role, Object policy );
void release( Token token, Object object );
void releaseAll( Token token );
}
or just:
interface SeviceResolver
{
Object lookup( String role );
Object lookup( String role, Object policy );
void release( Object object );
}
> Before I go and vote for this one, I would also like to hear more
> about Peter's release-less version. If that one works, we could have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object policy );
> }
I'm afraid this would only work for thread-safe services because of the
following fundamental issue (a quote from my previous mail to Peter):
"Stating that the resources will be released at the end of the request,
just moves the "token creation" to a higher level. Only the component
using the resource knows exactly when to release it, so for optimal
performance, there must be a way for the component to indicate this
(e.g. by calling release()). The container is then free to take any
action it sees fit, so the clear IOC remains."
One way around this would be to use something like:
interface ServiceManager
{
Object invoke( String role, String operation,
String[] signature, Object[] params );
}
But IMO this has WAY too many other implications.
So, it looks like we need release(), the question is where...
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin:
>
> Based on the proposal here (which I like) I would like to go ahead
> and synchronise the proposal in src/proposal/service. Based on
> what I've read below, both proposals are equivalent at the service
> manager level. I would like to update the proposal (which I'm
> currently using under an adapted version of Phoenix, and related
> pipeline tool, and business application) to be basically in sync.
> with what you have proposed. Before doing that I just wanted
> confirm that from you point of view the "token" aspect is not on
> the immediate agenda (which of course simplifies things to some
> degree).
I agree with everything here. Yes, the Token has to be put on the
backburner for the time being.
We do need to go for final vote, but hopefully we can get this all
behind us.
The biggest thing that might need to change is the merging of
Resolver and ReleasableResolver. It is not clear how to enforce
a release policy without kluges in the client code.
>
> Cheers, Steve.
>
> p.s. I'm hoping that whatever comes out of this to be friendly
> towards the future introduction of token based service pooling!
:)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Berin:
Based on the proposal here (which I like) I would like to go ahead
and synchronise the proposal in src/proposal/service. Based on
what I've read below, both proposals are equivalent at the service
manager level. I would like to update the proposal (which I'm
currently using under an adapted version of Phoenix, and related
pipeline tool, and business application) to be basically in sync.
with what you have proposed. Before doing that I just wanted
confirm that from you point of view the "token" aspect is not on
the immediate agenda (which of course simplifies things to some
degree).
Cheers, Steve.
p.s. I'm hoping that whatever comes out of this to be friendly
towards the future introduction of token based service pooling!
SJM
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, 18 February, 2002 18:16
> To: Avalon Developers List
> Cc: Stephen McConnell
> Subject: Re: Son of ComponentManager
>
>
> In the end, we have these requirements (things we currently
> defined as needs)
>
> 1) Ability to test if a resource exists in the Manager
> - Allows conditional lookups without hefty exception handling
> - Usually lighter & quicker than the full lookup method
>
> 2) Ability to release resources
> - Some resources are pooled, and the explicit test to see if
> a resource is
> poolable is bad, and a step backwards
> - A standard and uniform approach for all components is
> better than special
> handling for a certain class of components--esp. when the
> policy of whether
> a component is Pooled or not is dependant on the Container
> implementation
> - Switching containers needs to be as painless as possible,
> therefore we cannot
> have different request semantics for a resource.
>
> 3) Ability to retrieve arbitrary resources from one interface
> - We cannot use the term Component or Service because Object
> is too general,
> therfore we use the term Resource
> - By restricting to Component the implementation is too restrictive
>
> 4) Ability to retrieve specific instance of a class of resource
> if multiple exist
> - Currently supplied by ComponentSelector interface--but
> semantics are clumsy
> - It would be preferable to merge the ComponentSelector
> select() method in with
> the lookup. In effect, make a Query out of a call.
>
> My proposed solution (as of right now) to support these NEEDS is this:
>
> Resolver
> {
> Object resolve( String key );
> boolean hasResource( String key );
> }
>
> ReleasableResolver extends Resolver
> {
> void release( Object resource );
> }
>
> QueriableResolver extends Resolver
> {
> Object resolve( String key, Object hint );
> boolean hasResource( String key, Object hint );
> }
>
> QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
> {}
>
>
> This provides a solution where we can have a default interface
> that does not
> support pooled resources to satisfy the simplest needs (aka Peter
> and Stephen's
> needs). We have a version that allows you to release components
> when you may
> have pooled resources. We also have a version that allows you to
> do simple
> or complex queries based on a single key. Lastly we have a version that
> merges the pooled resource and query support.
>
> Unfortunately, while Tokens are a cool idea--they would have to
> be moved to
> a RequestResovler or some instance like that. Alternatively, we can have
> a Token object like I described earlier that you register your resources
> with, and release right away.
>
> Please post your comments.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> In the end, we have these requirements (things we currently
> defined as needs)
>
> 1) Ability to test if a resource exists in the Manager
> - Allows conditional lookups without hefty exception handling
> - Usually lighter & quicker than the full lookup method
>
> 2) Ability to release resources
> - Some resources are pooled, and the explicit test to see if
> a resource is
> poolable is bad, and a step backwards
> - A standard and uniform approach for all components is
> better than special
> handling for a certain class of components--esp. when the
> policy of whether
> a component is Pooled or not is dependant on the Container
> implementation
> - Switching containers needs to be as painless as possible,
> therefore we cannot
> have different request semantics for a resource.
>
> 3) Ability to retrieve arbitrary resources from one interface
> - We cannot use the term Component or Service because Object
> is too general,
> therfore we use the term Resource
> - By restricting to Component the implementation is too restrictive
>
> 4) Ability to retrieve specific instance of a class of resource
> if multiple exist
> - Currently supplied by ComponentSelector interface--but
> semantics are clumsy
> - It would be preferable to merge the ComponentSelector
> select() method in with
> the lookup. In effect, make a Query out of a call.
>
> My proposed solution (as of right now) to support these NEEDS is this:
>
> Resolver
> {
> Object resolve( String key );
> boolean hasResource( String key );
> }
>
> ReleasableResolver extends Resolver
> {
> void release( Object resource );
> }
>
> QueriableResolver extends Resolver
> {
> Object resolve( String key, Object hint );
> boolean hasResource( String key, Object hint );
> }
>
> QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
> {}
>
>
> This provides a solution where we can have a default interface
> that does not
> support pooled resources to satisfy the simplest needs (aka Peter
> and Stephen's
> needs). We have a version that allows you to release components
> when you may
> have pooled resources. We also have a version that allows you to
> do simple
> or complex queries based on a single key. Lastly we have a version that
> merges the pooled resource and query support.
>
> Unfortunately, while Tokens are a cool idea--they would have to
> be moved to
> a RequestResovler or some instance like that. Alternatively, we can have
> a Token object like I described earlier that you register your resources
> with, and release right away.
>
> Please post your comments.
Basically one: What lifestyle interface will replace Composable?
Will it be
interface XXXXX {
void X (QueriableReleasableResolver resolver);
}
or
interface XXXXX {
void X (ReleasableResolver resolver);
}
or
interface XXXXX {
void X (QueriableResolver resolver);
}
or
interface XXXXX {
void X (Resolver resolver);
}
or
...
?
By your list of *needs*, we *need* a QueriableReleasableResolver.
So why not just call it Resolver and stuff all methods into it?
Why do we need an interface that does not support pooling? All
we get from that is decreased maintainability of the code as you
have to write code for a) manager supports pooling and b) manager
doesn't.
I thought the whole point of interfaces was to be able to plug
in an implementation behind it. If pooling is supported or not
should be something for the implementation, not for the client
to know.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin,
I like the proposal, but there's one point I'd like to make. Role based
lookups are about:
"Who handles the specified role in this environment?"
So, having the following would make no sense:
resolver.lookup( "jndi://com.domain.BusinessInterface" );
resolver.lookup( "rmi://com.domain.BusinessInterface" );
resolver.lookup( "corba://com.domain.BusinessInterface" );
From the client's point of view, it should always be:
resolver.lookup( "role://com.domain.BusinessInterface" );
// or resolver.lookup( "com.domain.BusinessInterface" );
// or resolver.lookup( "ShorthandName" );
Regardless of where the component is found. I'm not saying you suggested
otherwise, but wanted to make sure we're all clear on this.
Now, the question is: should the concern of role based lookups be
separated into a dedicated interface?
(: A ;)
--
Antti Koivunen (Mr.) <an...@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Peter Donald <pe...@apache.org>.
On Tue, 19 Feb 2002 07:21, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Tue, 19 Feb 2002 06:05, Berin Loritsch wrote:
> >>In Phoenix, Blocks only need the core Resolver interface, so they don't
> >>need to do anything special. The initialize() method would look like
> >> this:
> >>
> >>(DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
> >>
> >>In the event we are using it to lookup file resources, we would have
> >>something like this:
> >>
> >>(Resource) m_resolver.lookup( "context://my/file.xml" );
> >
> > So you are wanting to merge CM and Context?
>
> Not exactly, although that would be possible. The "context:" psuedo
> protocol as defined in Cocoon is any File resource that is within
> Cocoon's context directory. Not the Context object.
Im uncomfortable with that. Why not have a FileService object in CM that can
grab the file resource?
--
Cheers,
Pete
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 19 Feb 2002 06:05, Berin Loritsch wrote:
>
>>In Phoenix, Blocks only need the core Resolver interface, so they don't
>>need to do anything special. The initialize() method would look like this:
>>
>>(DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
>>
>>In the event we are using it to lookup file resources, we would have
>>something like this:
>>
>>(Resource) m_resolver.lookup( "context://my/file.xml" );
>>
>
> So you are wanting to merge CM and Context?
Not exactly, although that would be possible. The "context:" psuedo
protocol as defined in Cocoon is any File resource that is within
Cocoon's context directory. Not the Context object.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Peter Donald <pe...@apache.org>.
On Tue, 19 Feb 2002 06:05, Berin Loritsch wrote:
> In Phoenix, Blocks only need the core Resolver interface, so they don't
> need to do anything special. The initialize() method would look like this:
>
> (DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
>
> In the event we are using it to lookup file resources, we would have
> something like this:
>
> (Resource) m_resolver.lookup( "context://my/file.xml" );
So you are wanting to merge CM and Context?
--
Cheers,
Pete
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 18 februari 2002 20:32
> To: Avalon Developers List
> Subject: Re: Son of ComponentManager
>
>
> Leo Sutic wrote:
> >
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> >>QueriableResolver m_resolver;
> >>
> >>void setResolver (Resolver resolver)
> >>{
> >> m_resolver = (QueriableResolver)resolver; // policy is system wide
> >>}
> >>
> >>void myMethod( Environment e )
> >>{
> >> Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
> >> Transformer specificTrans =
> >>m_resolver.lookup(Transformer.ROLE, "specific");
> >> Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
> >>}
> >>
> >>As you can see the policy is set system wide. You have the
> >>flexibility to do
> >>what you need, with an interface that is easy to use. It makes
> >>the easy stuff
> >>easy, and the hard stuff possible.
> >>
> >
> > Berin,
> >
> > the above is exactly what I want, BUT: Where in the contract for
> > setResolver does it say that
> >
> > (QueriableResolver) resolver
> >
> > is a legal operation?
> >
> > Will it not be necessary to define it as:
> >
> > void setResolver (QueriableResolver resolver)
> >
> > to avoid a potentially harmful downcast?
>
>
> One solution is to have a matching interface for each type of Resolver.
Not really a solution. Unless you merge Resolver and ReleaseableResolver,
you can not plug a component that uses Resolver into a system that
uses pooled components.
> Another solution is to merge all Resolvers into one interface.
I would go for this one.
Let the hint in:
Object resolve( String key, Object hint );
boolean hasResource( String key, Object hint );
be optional and implement
Object resolve( String key, Object hint );
as
resolve( key );
in implementations that do not support selection. After all, all
the Resolver interface guarantees is the type of the returned
object (= equal to the role).
> There
> are some sound arguments both for and against it. It's a tradeoff issue.
> Another solution is to design Components for one type of Resolver--so that
> it simply doesn't work if you don't supply the resolver. And lastly
> you can always have a getType() method.
>
> I am -1 on the getType method, as I think it is not really the
> best solution.
With you there.
> We also have to consider where we want to encourage people to go. The
> best systems will most likely be the ones that work with the
> simple Resolver
> interface--therefore that is what we want to encourage. I.e. one
> Resolvable
> interface that sets the Resolver for the class.
Then no component can be plugged into an environment that has pooled
components, as no component written for Resolver will ever call release().
-1 on that.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>QueriableResolver m_resolver;
>>
>>void setResolver (Resolver resolver)
>>{
>> m_resolver = (QueriableResolver)resolver; // policy is system wide
>>}
>>
>>void myMethod( Environment e )
>>{
>> Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
>> Transformer specificTrans =
>>m_resolver.lookup(Transformer.ROLE, "specific");
>> Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
>>}
>>
>>As you can see the policy is set system wide. You have the
>>flexibility to do
>>what you need, with an interface that is easy to use. It makes
>>the easy stuff
>>easy, and the hard stuff possible.
>>
>
> Berin,
>
> the above is exactly what I want, BUT: Where in the contract for
> setResolver does it say that
>
> (QueriableResolver) resolver
>
> is a legal operation?
>
> Will it not be necessary to define it as:
>
> void setResolver (QueriableResolver resolver)
>
> to avoid a potentially harmful downcast?
One solution is to have a matching interface for each type of Resolver.
Another solution is to merge all Resolvers into one interface. There
are some sound arguments both for and against it. It's a tradeoff issue.
Another solution is to design Components for one type of Resolver--so that
it simply doesn't work if you don't supply the resolver. And lastly
you can always have a getType() method.
I am -1 on the getType method, as I think it is not really the best solution.
We also have to consider where we want to encourage people to go. The
best systems will most likely be the ones that work with the simple Resolver
interface--therefore that is what we want to encourage. I.e. one Resolvable
interface that sets the Resolver for the class.
It is guaranteed to support the core contracts of resolve() and hasResource().
It would be a step backwards to require a Component to test for which specific
Resolver it receives.
The best solution given this scenario is that all Components should expect
the minimum that is required.
I might even lean toward the merging of ReleasableResolver and Resolver--simply
because that gives the component the instructions that all requested Resources
must be released.
Most Resolvers are going to be set for a specific system. I feel like I have
diarrea of the brain right now, so I don't feel like I am communicating effectively.
I think I need to have my PLC (Post Lunch Coffee)....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> QueriableResolver m_resolver;
>
> void setResolver (Resolver resolver)
> {
> m_resolver = (QueriableResolver)resolver; // policy is system wide
> }
>
> void myMethod( Environment e )
> {
> Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
> Transformer specificTrans =
> m_resolver.lookup(Transformer.ROLE, "specific");
> Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
> }
>
> As you can see the policy is set system wide. You have the
> flexibility to do
> what you need, with an interface that is easy to use. It makes
> the easy stuff
> easy, and the hard stuff possible.
Berin,
the above is exactly what I want, BUT: Where in the contract for
setResolver does it say that
(QueriableResolver) resolver
is a legal operation?
Will it not be necessary to define it as:
void setResolver (QueriableResolver resolver)
to avoid a potentially harmful downcast?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline,
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, February 18, 2002 8:06 PM
>
> Paulo Gaspar wrote:
> > Hi Berin,
> >
> >
> >
> > This is the final bit of my lookup() method:
> >
> > if (factory.getLifeStyle().mustBeReleased())
> > {
> > m_activeComponents.register(factory, i_token, component);
> > }
> >
> > return component;
> > }
> >
> > I think it is quite generic.
>
> Yes, assuming the Token aspect is part of the core. Looking at the
> current needs and comments, we would have to retrofit the Token.
>
> Also keep in mind that according to my tests, there is little to be
> gained by not releasing certain components as opposed to others.
What you save is on the tracking itself.
> > I still think there should be a base ObjectManager on top of
> > which you could have a ComponentManager or a ServiceManager
> > or whatever...
>
> Compiler usually complains when you specialize return methods.
1- I am not sure if you should use anything different from Object
as a return type for either;
2- I was talking wrapper here.
> > ...
> >
> >>4) Ability to retrieve specific instance of a class of resource
> >>if multiple exist
> >> - Currently supplied by ComponentSelector interface--but
> >>semantics are clumsy
> >> - It would be preferable to merge the ComponentSelector
> >>select() method in with
> >> the lookup. In effect, make a Query out of a call.
> >>
> >
> > Actually, me thinks you are talking "indexing strategies"
> > again/yet.
> >
> > IMO there are a lot and the world population will never agree
> > about using just a couple of them.
>
> The reason I have String, Object is to allow the ability for the
> Container to mandate the policy. IOW, In Cocoon, the String is
> the role of the component we need, where the Object can be the
> Environment object and complex decisions based on the Environment
> can be made.
Ok, Cocoon and other current projects are the only possible users
of Avalon then. So I am out.
> >> ...
> >
> > I still don't "get" your resolvers!
> >
> > Little sample of a bit of app code using them???
> > Pleaaaseeee!!!
>
> A Resolver is another name for the
> ComponentManager/ServiceManager/ObjectManager
> that basically has one function. Resolve request X with resource
> Y. It is
> very simple.
>
> In Phoenix, Blocks only need the core Resolver interface, so they
> don't need
> to do anything special. The initialize() method would look like this:
>
> (DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
>
> In the event we are using it to lookup file resources, we would
> have something
> like this:
>
> (Resource) m_resolver.lookup( "context://my/file.xml" );
>
> If we needed a JNDI, RMI, or CORBA resource, we can lookup our
> resources like
> this:
>
> {JNDIObject) resolver.lookup("jndi://context/JNDIObject");
> (RMIObject) resolver.lookup("rmi://rmiresource");
> (CORBAObject) resolver.lookup("corba://namingdirectory/object");
>
> The all the keys go to the Container which manages the policies
> of the "psuedo"
> protocols or whatever the lookup policy is. It is a function of
> the Container
> to provide the resources that the children need. One simple
> interface to allow
> that to happen makes the system easier to use.
>
> People are familiar with the concepts of a protocol, and know
> that they expect
> the system to behave in a certain manner when they use that
> protocol. Granted,
> I am perfectly fine with doing away with the concept of protocol.
>
> The whole purpose of using a String is that the Container can be
> as simple or
> as flexible as you need.
>
> Simple component resolution is the core responsibility, although
> you can lookup
> other types of resources.
>
> In cases where you need a specific instance of a Component you
> use the QueriableResolver.
>
> QueriableResolver m_resolver;
>
> void setResolver (Resolver resolver)
> {
> m_resolver = (QueriableResolver)resolver; // policy is system wide
> }
>
> void myMethod( Environment e )
> {
> Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
> Transformer specificTrans =
> m_resolver.lookup(Transformer.ROLE, "specific");
> Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
> }
>
> As you can see the policy is set system wide. You have the
> flexibility to do
> what you need, with an interface that is easy to use. It makes
> the easy stuff
> easy, and the hard stuff possible.
So, if I want to use your string-based resolver I have to either:
(1) Use LDAP or JNDI;
(2) Create my own (amybe URI-like) protocol and build a parser
for it.
I really fail to see why is this better than using an Object as a
key. If an Object is the key I just have to create a Key/Query
class to hold all the possible parameters I am using... or even
just use a String if I just want a Role key or something like
that.
And it also does not stop you from using URI's... but it allows
you to use simpler solutions too.
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
Paulo Gaspar wrote:
> Hi Berin,
>
>
>
> This is the final bit of my lookup() method:
>
> if (factory.getLifeStyle().mustBeReleased())
> {
> m_activeComponents.register(factory, i_token, component);
> }
>
> return component;
> }
>
> I think it is quite generic.
Yes, assuming the Token aspect is part of the core. Looking at the
current needs and comments, we would have to retrofit the Token.
Also keep in mind that according to my tests, there is little to be
gained by not releasing certain components as opposed to others.
> I still think there should be a base ObjectManager on top of
> which you could have a ComponentManager or a ServiceManager
> or whatever...
Compiler usually complains when you specialize return methods.
>
>>>From a previous post I made to which I noticed no reaction:
>
>
>>-----Original Message-----
>>From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
>>Sent: Thursday, February 14, 2002 2:16 PM
>>To: Avalon Developers List; mcconnell@apache.org
>>Subject: RE: [VOTE] RE: ComponentManager interface
>>
>>...
>>
>>So, what I want to say is that I consider the problem of
>>managing objects-with-a-LifeStyle important enough to deserve
>>a separate layer. Then you could have
>>
>> ObjectManagerImplementation
>> |
>> ObjectManager
>> (interface)
>> |
>> ComponentManagerWrapper
>> |
>> ComponentManager
>> (interface)
>>
>>Meaning that you could have a specific implementation of an
>>ObjectManager interface which, using a ComponentManager
>>wrapper is exposed as a ComponentManager. The wrapper being
>>something like the ClassicCM class in
>>
>>http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06057.html
:/ I'm not sold. A simple interface without specific wrappers
are good enough.
>
>
>>4) Ability to retrieve specific instance of a class of resource
>>if multiple exist
>> - Currently supplied by ComponentSelector interface--but
>>semantics are clumsy
>> - It would be preferable to merge the ComponentSelector
>>select() method in with
>> the lookup. In effect, make a Query out of a call.
>>
>
> Actually, me thinks you are talking "indexing strategies"
> again/yet.
>
> IMO there are a lot and the world population will never agree
> about using just a couple of them.
The reason I have String, Object is to allow the ability for the
Container to mandate the policy. IOW, In Cocoon, the String is
the role of the component we need, where the Object can be the
Environment object and complex decisions based on the Environment
can be made.
>>My proposed solution (as of right now) to support these NEEDS is this:
>>
>>Resolver
>>{
>> Object resolve( String key );
>> boolean hasResource( String key );
>>}
>>
>>ReleasableResolver extends Resolver
>>{
>> void release( Object resource );
>>}
>>
>>QueriableResolver extends Resolver
>>{
>> Object resolve( String key, Object hint );
>> boolean hasResource( String key, Object hint );
>>}
>>
>>QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
>>{}
>>
>>
>>This provides a solution where we can have a default interface
>>that does not
>>support pooled resources to satisfy the simplest needs (aka Peter
>>and Stephen's
>>needs). We have a version that allows you to release components
>>when you may
>>have pooled resources. We also have a version that allows you to
>>do simple
>>or complex queries based on a single key. Lastly we have a version that
>>merges the pooled resource and query support.
>>
>>Unfortunately, while Tokens are a cool idea--they would have to
>>be moved to
>>a RequestResovler or some instance like that. Alternatively, we can have
>>a Token object like I described earlier that you register your resources
>>with, and release right away.
>>
>>Please post your comments.
>>
>
> I still don't "get" your resolvers!
>
> Little sample of a bit of app code using them???
> Pleaaaseeee!!!
A Resolver is another name for the ComponentManager/ServiceManager/ObjectManager
that basically has one function. Resolve request X with resource Y. It is
very simple.
In Phoenix, Blocks only need the core Resolver interface, so they don't need
to do anything special. The initialize() method would look like this:
(DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
In the event we are using it to lookup file resources, we would have something
like this:
(Resource) m_resolver.lookup( "context://my/file.xml" );
If we needed a JNDI, RMI, or CORBA resource, we can lookup our resources like
this:
{JNDIObject) resolver.lookup("jndi://context/JNDIObject");
(RMIObject) resolver.lookup("rmi://rmiresource");
(CORBAObject) resolver.lookup("corba://namingdirectory/object");
The all the keys go to the Container which manages the policies of the "psuedo"
protocols or whatever the lookup policy is. It is a function of the Container
to provide the resources that the children need. One simple interface to allow
that to happen makes the system easier to use.
People are familiar with the concepts of a protocol, and know that they expect
the system to behave in a certain manner when they use that protocol. Granted,
I am perfectly fine with doing away with the concept of protocol.
The whole purpose of using a String is that the Container can be as simple or
as flexible as you need.
Simple component resolution is the core responsibility, although you can lookup
other types of resources.
In cases where you need a specific instance of a Component you use the QueriableResolver.
QueriableResolver m_resolver;
void setResolver (Resolver resolver)
{
m_resolver = (QueriableResolver)resolver; // policy is system wide
}
void myMethod( Environment e )
{
Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
Transformer specificTrans = m_resolver.lookup(Transformer.ROLE, "specific");
Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
}
As you can see the policy is set system wide. You have the flexibility to do
what you need, with an interface that is easy to use. It makes the easy stuff
easy, and the hard stuff possible.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin,
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, February 18, 2002 6:16 PM
>
> In the end, we have these requirements (things we currently
> defined as needs)
>
> 1) Ability to test if a resource exists in the Manager
> - Allows conditional lookups without hefty exception handling
> - Usually lighter & quicker than the full lookup method
+1 if I could
> 2) Ability to release resources
> - Some resources are pooled, and the explicit test to see if
> a resource is
> poolable is bad, and a step backwards
> - A standard and uniform approach for all components is
> better than special
> handling for a certain class of components--esp. when the
> policy of whether
> a component is Pooled or not is dependant on the Container
> implementation
> - Switching containers needs to be as painless as possible,
> therefore we cannot
> have different request semantics for a resource.
This is the final bit of my lookup() method:
if (factory.getLifeStyle().mustBeReleased())
{
m_activeComponents.register(factory, i_token, component);
}
return component;
}
I think it is quite generic.
> 3) Ability to retrieve arbitrary resources from one interface
> - We cannot use the term Component or Service because Object
> is too general,
> therfore we use the term Resource
> - By restricting to Component the implementation is too restrictive
+1 if I could.
I still think there should be a base ObjectManager on top of
which you could have a ComponentManager or a ServiceManager
or whatever...
>From a previous post I made to which I noticed no reaction:
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Thursday, February 14, 2002 2:16 PM
> To: Avalon Developers List; mcconnell@apache.org
> Subject: RE: [VOTE] RE: ComponentManager interface
>
> ...
>
> So, what I want to say is that I consider the problem of
> managing objects-with-a-LifeStyle important enough to deserve
> a separate layer. Then you could have
>
> ObjectManagerImplementation
> |
> ObjectManager
> (interface)
> |
> ComponentManagerWrapper
> |
> ComponentManager
> (interface)
>
> Meaning that you could have a specific implementation of an
> ObjectManager interface which, using a ComponentManager
> wrapper is exposed as a ComponentManager. The wrapper being
> something like the ClassicCM class in
>
> http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06057.html
>
>
> This means that you could easily replace the underlying
> object management implementation with ease and even reuse
> it for a ServiceManager like:
>
> ObjectManagerImplementation
> |
> ObjectManager
> (interface)
> |
> ServiceManagerWrapper
> |
> ServiceManager
> (interface)
>
> ...............
> 4) Ability to retrieve specific instance of a class of resource
> if multiple exist
> - Currently supplied by ComponentSelector interface--but
> semantics are clumsy
> - It would be preferable to merge the ComponentSelector
> select() method in with
> the lookup. In effect, make a Query out of a call.
Actually, me thinks you are talking "indexing strategies"
again/yet.
IMO there are a lot and the world population will never agree
about using just a couple of them.
> My proposed solution (as of right now) to support these NEEDS is this:
>
> Resolver
> {
> Object resolve( String key );
> boolean hasResource( String key );
> }
>
> ReleasableResolver extends Resolver
> {
> void release( Object resource );
> }
>
> QueriableResolver extends Resolver
> {
> Object resolve( String key, Object hint );
> boolean hasResource( String key, Object hint );
> }
>
> QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
> {}
>
>
> This provides a solution where we can have a default interface
> that does not
> support pooled resources to satisfy the simplest needs (aka Peter
> and Stephen's
> needs). We have a version that allows you to release components
> when you may
> have pooled resources. We also have a version that allows you to
> do simple
> or complex queries based on a single key. Lastly we have a version that
> merges the pooled resource and query support.
>
> Unfortunately, while Tokens are a cool idea--they would have to
> be moved to
> a RequestResovler or some instance like that. Alternatively, we can have
> a Token object like I described earlier that you register your resources
> with, and release right away.
>
> Please post your comments.
I still don't "get" your resolvers!
Little sample of a bit of app code using them???
Pleaaaseeee!!!
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>
>
> In the end, we have these requirements (things we currently
> defined as needs)
>
> 1) Ability to test if a resource exists in the Manager
> - Allows conditional lookups without hefty exception
> handling
> - Usually lighter & quicker than the full lookup method
>
> 2) Ability to release resources
> - Some resources are pooled, and the explicit test to
> see if a resource is poolable is bad, and a step backwards
> - A standard and uniform approach for all components is
> better than special handling for a certain class of
> components--esp. when the policy of whether a component is
> Pooled or not is dependant on the Container implementation
> - Switching containers needs to be as painless as possible,
> therefore we cannot have different request semantics for
> a resource.
>
> 3) Ability to retrieve arbitrary resources from one interface
> - We cannot use the term Component or Service because Object
> is too general, therfore we use the term Resource
Just a quick (trivial) note - as Service is undefined within the
scope of the framework I consider this name as available and appropriate.
Resource (for me ... due to OMG background) is really loaded and there is
the added conflict with the usage of Resource in the internationalisation
stuff. I definitely prefer Service over Resource (but I'm not going to
make a big thing about it because I need a solution).
> - By restricting to Component the implementation is too restrictive
>
> 4) Ability to retrieve specific instance of a class of resource
> if multiple exist
> - Currently supplied by ComponentSelector interface--but
> semantics are clumsy
> - It would be preferable to merge the ComponentSelector
> select() method in with
> the lookup. In effect, make a Query out of a call.
>
> My proposed solution (as of right now) to support these NEEDS is this:
>
> Resolver
> {
> Object resolve( String key );
> boolean hasResource( String key );
> }
+1 clean and unambigouse.
> ReleasableResolver extends Resolver
> {
> void release( Object resource );
> }
+1 seperation of concerns.
> QueriableResolver extends Resolver
> {
> Object resolve( String key, Object hint );
> boolean hasResource( String key, Object hint );
> }
Given that tokens are not in the proposal, then +1.
I would prefer "hint" to be renamed to "policy" or "criteria".
Hint has an approximation with "something close to" whereas a "policy"
or "criteria" is expression of what you "require".
> QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
> {}
>
>
> This provides a solution where we can have a default interface
> that does not support pooled resources to satisfy the simplest needs
> (aka Peter and Stephen's needs). We have a version that allows you to
> release components when you may have pooled resources. We also have a
> version that allows you to do simple or complex queries based on a single
> key. Lastly we have a version that merges the pooled resource and query
> support.
>
> Unfortunately, while Tokens are a cool idea--they would have to
> be moved to a RequestResovler or some instance like that. Alternatively,
> we can have a Token object like I described earlier that you register your
> resources with, and release right away.
I'm in favour of that - enables cleaner seperation.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
In the end, we have these requirements (things we currently defined as needs)
1) Ability to test if a resource exists in the Manager
- Allows conditional lookups without hefty exception handling
- Usually lighter & quicker than the full lookup method
2) Ability to release resources
- Some resources are pooled, and the explicit test to see if a resource is
poolable is bad, and a step backwards
- A standard and uniform approach for all components is better than special
handling for a certain class of components--esp. when the policy of whether
a component is Pooled or not is dependant on the Container implementation
- Switching containers needs to be as painless as possible, therefore we cannot
have different request semantics for a resource.
3) Ability to retrieve arbitrary resources from one interface
- We cannot use the term Component or Service because Object is too general,
therfore we use the term Resource
- By restricting to Component the implementation is too restrictive
4) Ability to retrieve specific instance of a class of resource if multiple exist
- Currently supplied by ComponentSelector interface--but semantics are clumsy
- It would be preferable to merge the ComponentSelector select() method in with
the lookup. In effect, make a Query out of a call.
My proposed solution (as of right now) to support these NEEDS is this:
Resolver
{
Object resolve( String key );
boolean hasResource( String key );
}
ReleasableResolver extends Resolver
{
void release( Object resource );
}
QueriableResolver extends Resolver
{
Object resolve( String key, Object hint );
boolean hasResource( String key, Object hint );
}
QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
{}
This provides a solution where we can have a default interface that does not
support pooled resources to satisfy the simplest needs (aka Peter and Stephen's
needs). We have a version that allows you to release components when you may
have pooled resources. We also have a version that allows you to do simple
or complex queries based on a single key. Lastly we have a version that
merges the pooled resource and query support.
Unfortunately, while Tokens are a cool idea--they would have to be moved to
a RequestResovler or some instance like that. Alternatively, we can have
a Token object like I described earlier that you register your resources
with, and release right away.
Please post your comments.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Hi Paulo:
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Monday, 18 February, 2002 17:57
> To: Avalon Developers List; Stephen McConnell
> Subject: RE: Son of ComponentManager
>
>
> Well, IMO either the CM (or OM) tracks the components or it
> does not.
>
> Imagine that you start a project using a non-managed policy
> (no tokens) and than want to convert to a managed policy. If
> you have separated interfaces the compiler will help you
> tracking all the stuff you have to change after you change
> the type of the CM you are using, otherwise you are on your
> own to search and replace all the stuff throughout the code.
>
> Besides, this method
> release(Object comp)
> as a different meaning for a managed CM than it as for a
> non-managed CM:
> - For a non-managed one it means "just release this
> component";
> - For a managed one it means "release this component and
> stop tracking it so you don't try to release it again
> when I use the releaseAll(token)".
Agreed.
> Of course that you could also have a managed version like
> release(Object token, Object comp)
> but then, it gets again more confusing and harder to use.
Yep.
> It is not that I think that EVERYTHING must be type safe
> and hyper safe, but when there is an obvious way to make
> things safer without too much cost...
My impression is that the question is comming down to cost.
I'm definately leaning on the conservative side bacause I
know that components I'm developing will be plugged into
serviceable objects that I know nothing about. The tigher
the contract at a compilation level the better bacause that
means more issues are trapped in develper space and less in
runtime (and runtime is much more costly).
> I only have a managed CM,
ALmost the same case here - 95%/5% split.
> but if you really want both I
> really thing that the best is to have both these
> interfaces:
>
> public interface ComponentManager // non-managed
> {
> Object lookup( String role );
> Object lookup( String role, Object policy );
>
> void release( Object object );
> }
>
> public interface ManagedComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Object policy );
>
> void release( Object component );
> void releaseAll( Object token );
> }
>
> AND don't implement both in the same class!
Which is simple to enforce by changing the name from "lookup" to
"release" :-) ... compile time enforcement.
> (I still miss the hasComponent() methods.)
>
> As mentioned before, the reason for the
> release( Object component );
> method is to free ASAP valuable/scarce resource, like
> database connections and so.
>
>
> Does this make sense to you?
Yes it does.
Cheers, Steve.
> (I am coding too much these days and when this happens
> I become a much worse communicator.)
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > Sent: Monday, February 18, 2002 7:34 AM
> > To: Avalon Developers List; paulo.gaspar@krankikom.de
> > Subject: RE: Son of ComponentManager
> >
> >
> >
> > Paulo:
> >
> > I agree with your point concerning the mixing of token and
> > non-token methods in the same interface (at least methods
> > with the same name). That was one of the reasons I attempted
> > to separate out the token based methods using the "checkout"
> > method name. I don't see any complication in dropping back
> > to that. But can you confirm if that addresses the point your
> > raising?
> >
> > Cheers, Steve.
> >
> >
> > > -----Original Message-----
> > > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > > Sent: Monday, 18 February, 2002 00:44
> > > To: Avalon Developers List
> > > Subject: RE: Son of ComponentManager
> > >
> > >
> > > I already advised AGAINST using methods with-token and
> > > without-token in the same interface. Did you notice that
> > > posting?
> > >
> > > IMO it is VERY error prone.
> > >
> > >
> > > Have fun,
> > > Paulo Gaspar
> > >
> > > > -----Original Message-----
> > > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > > Sent: Sunday, February 17, 2002 6:26 PM
> > > > To: Avalon Developers List
> > > > Subject: RE: Son of ComponentManager
> > > >
> > > >
> > > >
> > > >
> > > > > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > > > >
> > > > > Here is consolidation of the interfaces based on a logical
> > > extrapolation
> > > > > of the conclusions reached under this thread:
> > > > >
> > > > > interface Serviceable
> > > > > {
> > > > > public void service( ServiceManager manager ) throws
> > > > > ServiceException;
> > > > > }
> > > > >
> > > > > interface ServiceManager
> > > > > {
> > > > > Object lookup( String role );
> > > > > boolean hasService( String role );
> > > > > }
> > > > >
> > > > > interface ServiceSelector
> > > > > {
> > > > > Object select( Object policy );
> > > > > boolean isSelectable( Object policy );
> > > > > }
> > > > >
> > > > > interface ServiceResolver extends ServiceManager
> > > > > {
> > > > > Object lookup( String role, Object token );
> > > > > void release( Object object );
> > > > > void releaseAll( Object token );
> > > > > }
> > > > >
> > > > > interface PooledSelector extends ServiceSelector
> > > > > {
> > > > > Object select( Object token, Object policy );
> > > > > }
> > > > >
> > > > > Over to you.
> > > >
> > > > Got the correction:
> > > >
> > > > interface Resolvable {
> > > > public void resolve( ServiceResolver resolver ) throws
> > > > ExceptionThrownWhenLookupFails;
> > > > }
> > > >
> > > > Where does the policy object in PooledSelector come from when a
> > > lookup is
> > > > done through a ServiceResolver? Isn't it necessary to have:
> > > >
> > > > interface ServiceResolver extends ServiceManager
> > > > {
> > > > Object lookup( String role );
> > > > Object lookup( Object token, String role );
> > > >
> > > > Object lookup( String role, Object policy );
> > > > Object lookup( Object token, String role, Object policy );
> > > >
> > > > void release( Object object );
> > > > void releaseAll( Object token );
> > > > }
> > > >
> > > > where the policy object is passed along to the selector if present?
> > > >
> > > > Before I go and vote for this one, I would also like to hear more
> > > > about Peter's release-less version. If that one works, we
> could have:
> > > >
> > > > interface ServiceResolver extends ServiceManager
> > > > {
> > > > Object lookup( String role, Object policy );
> > > > }
> > > >
> > > > which is much cleaner. But it requires some other changes to
> > the way we
> > > > write
> > > > components. See:
> > > >
> > > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
> > > >
> > > > and my response:
> > > >
> > > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
> > > >
> > > > /LS
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Paulo Gaspar <pa...@krankikom.de>.
Well, IMO either the CM (or OM) tracks the components or it
does not.
Imagine that you start a project using a non-managed policy
(no tokens) and than want to convert to a managed policy. If
you have separated interfaces the compiler will help you
tracking all the stuff you have to change after you change
the type of the CM you are using, otherwise you are on your
own to search and replace all the stuff throughout the code.
Besides, this method
release(Object comp)
as a different meaning for a managed CM than it as for a
non-managed CM:
- For a non-managed one it means "just release this
component";
- For a managed one it means "release this component and
stop tracking it so you don't try to release it again
when I use the releaseAll(token)".
Of course that you could also have a managed version like
release(Object token, Object comp)
but then, it gets again more confusing and harder to use.
It is not that I think that EVERYTHING must be type safe
and hyper safe, but when there is an obvious way to make
things safer without too much cost...
I only have a managed CM, but if you really want both I
really thing that the best is to have both these
interfaces:
public interface ComponentManager // non-managed
{
Object lookup( String role );
Object lookup( String role, Object policy );
void release( Object object );
}
public interface ManagedComponentManager
{
Object lookup( Object token, String role );
Object lookup( Object token, String role, Object policy );
void release( Object component );
void releaseAll( Object token );
}
AND don't implement both in the same class!
(I still miss the hasComponent() methods.)
As mentioned before, the reason for the
release( Object component );
method is to free ASAP valuable/scarce resource, like
database connections and so.
Does this make sense to you?
(I am coding too much these days and when this happens
I become a much worse communicator.)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Monday, February 18, 2002 7:34 AM
> To: Avalon Developers List; paulo.gaspar@krankikom.de
> Subject: RE: Son of ComponentManager
>
>
>
> Paulo:
>
> I agree with your point concerning the mixing of token and
> non-token methods in the same interface (at least methods
> with the same name). That was one of the reasons I attempted
> to separate out the token based methods using the "checkout"
> method name. I don't see any complication in dropping back
> to that. But can you confirm if that addresses the point your
> raising?
>
> Cheers, Steve.
>
>
> > -----Original Message-----
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > Sent: Monday, 18 February, 2002 00:44
> > To: Avalon Developers List
> > Subject: RE: Son of ComponentManager
> >
> >
> > I already advised AGAINST using methods with-token and
> > without-token in the same interface. Did you notice that
> > posting?
> >
> > IMO it is VERY error prone.
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
> > > -----Original Message-----
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > Sent: Sunday, February 17, 2002 6:26 PM
> > > To: Avalon Developers List
> > > Subject: RE: Son of ComponentManager
> > >
> > >
> > >
> > >
> > > > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > > >
> > > > Here is consolidation of the interfaces based on a logical
> > extrapolation
> > > > of the conclusions reached under this thread:
> > > >
> > > > interface Serviceable
> > > > {
> > > > public void service( ServiceManager manager ) throws
> > > > ServiceException;
> > > > }
> > > >
> > > > interface ServiceManager
> > > > {
> > > > Object lookup( String role );
> > > > boolean hasService( String role );
> > > > }
> > > >
> > > > interface ServiceSelector
> > > > {
> > > > Object select( Object policy );
> > > > boolean isSelectable( Object policy );
> > > > }
> > > >
> > > > interface ServiceResolver extends ServiceManager
> > > > {
> > > > Object lookup( String role, Object token );
> > > > void release( Object object );
> > > > void releaseAll( Object token );
> > > > }
> > > >
> > > > interface PooledSelector extends ServiceSelector
> > > > {
> > > > Object select( Object token, Object policy );
> > > > }
> > > >
> > > > Over to you.
> > >
> > > Got the correction:
> > >
> > > interface Resolvable {
> > > public void resolve( ServiceResolver resolver ) throws
> > > ExceptionThrownWhenLookupFails;
> > > }
> > >
> > > Where does the policy object in PooledSelector come from when a
> > lookup is
> > > done through a ServiceResolver? Isn't it necessary to have:
> > >
> > > interface ServiceResolver extends ServiceManager
> > > {
> > > Object lookup( String role );
> > > Object lookup( Object token, String role );
> > >
> > > Object lookup( String role, Object policy );
> > > Object lookup( Object token, String role, Object policy );
> > >
> > > void release( Object object );
> > > void releaseAll( Object token );
> > > }
> > >
> > > where the policy object is passed along to the selector if present?
> > >
> > > Before I go and vote for this one, I would also like to hear more
> > > about Peter's release-less version. If that one works, we could have:
> > >
> > > interface ServiceResolver extends ServiceManager
> > > {
> > > Object lookup( String role, Object policy );
> > > }
> > >
> > > which is much cleaner. But it requires some other changes to
> the way we
> > > write
> > > components. See:
> > >
> > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
> > >
> > > and my response:
> > >
> > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
> > >
> > > /LS
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Paulo:
I agree with your point concerning the mixing of token and
non-token methods in the same interface (at least methods
with the same name). That was one of the reasons I attempted
to separate out the token based methods using the "checkout"
method name. I don't see any complication in dropping back
to that. But can you confirm if that addresses the point your
raising?
Cheers, Steve.
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Monday, 18 February, 2002 00:44
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
> I already advised AGAINST using methods with-token and
> without-token in the same interface. Did you notice that
> posting?
>
> IMO it is VERY error prone.
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > Sent: Sunday, February 17, 2002 6:26 PM
> > To: Avalon Developers List
> > Subject: RE: Son of ComponentManager
> >
> >
> >
> >
> > > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > >
> > > Here is consolidation of the interfaces based on a logical
> extrapolation
> > > of the conclusions reached under this thread:
> > >
> > > interface Serviceable
> > > {
> > > public void service( ServiceManager manager ) throws
> > > ServiceException;
> > > }
> > >
> > > interface ServiceManager
> > > {
> > > Object lookup( String role );
> > > boolean hasService( String role );
> > > }
> > >
> > > interface ServiceSelector
> > > {
> > > Object select( Object policy );
> > > boolean isSelectable( Object policy );
> > > }
> > >
> > > interface ServiceResolver extends ServiceManager
> > > {
> > > Object lookup( String role, Object token );
> > > void release( Object object );
> > > void releaseAll( Object token );
> > > }
> > >
> > > interface PooledSelector extends ServiceSelector
> > > {
> > > Object select( Object token, Object policy );
> > > }
> > >
> > > Over to you.
> >
> > Got the correction:
> >
> > interface Resolvable {
> > public void resolve( ServiceResolver resolver ) throws
> > ExceptionThrownWhenLookupFails;
> > }
> >
> > Where does the policy object in PooledSelector come from when a
> lookup is
> > done through a ServiceResolver? Isn't it necessary to have:
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( Object token, String role );
> >
> > Object lookup( String role, Object policy );
> > Object lookup( Object token, String role, Object policy );
> >
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > where the policy object is passed along to the selector if present?
> >
> > Before I go and vote for this one, I would also like to hear more
> > about Peter's release-less version. If that one works, we could have:
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role, Object policy );
> > }
> >
> > which is much cleaner. But it requires some other changes to the way we
> > write
> > components. See:
> >
> > http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
> >
> > and my response:
> >
> > http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
> >
> > /LS
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Paulo Gaspar <pa...@krankikom.de>.
I already advised AGAINST using methods with-token and
without-token in the same interface. Did you notice that
posting?
IMO it is VERY error prone.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Sunday, February 17, 2002 6:26 PM
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > Here is consolidation of the interfaces based on a logical extrapolation
> > of the conclusions reached under this thread:
> >
> > interface Serviceable
> > {
> > public void service( ServiceManager manager ) throws
> > ServiceException;
> > }
> >
> > interface ServiceManager
> > {
> > Object lookup( String role );
> > boolean hasService( String role );
> > }
> >
> > interface ServiceSelector
> > {
> > Object select( Object policy );
> > boolean isSelectable( Object policy );
> > }
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role, Object token );
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > interface PooledSelector extends ServiceSelector
> > {
> > Object select( Object token, Object policy );
> > }
> >
> > Over to you.
>
> Got the correction:
>
> interface Resolvable {
> public void resolve( ServiceResolver resolver ) throws
> ExceptionThrownWhenLookupFails;
> }
>
> Where does the policy object in PooledSelector come from when a lookup is
> done through a ServiceResolver? Isn't it necessary to have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role );
> Object lookup( Object token, String role );
>
> Object lookup( String role, Object policy );
> Object lookup( Object token, String role, Object policy );
>
> void release( Object object );
> void releaseAll( Object token );
> }
>
> where the policy object is passed along to the selector if present?
>
> Before I go and vote for this one, I would also like to hear more
> about Peter's release-less version. If that one works, we could have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object policy );
> }
>
> which is much cleaner. But it requires some other changes to the way we
> write
> components. See:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
>
> and my response:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stephen,
That's a very well thought proposal. The interfaces are clean and
unambiguous, but I do see one issue (described below, feel free to
comment). However, as Berin's latest proposal seems satisfactory, we
should probably continue the discussion there.
Stephen McConnell wrote:
>
> 1. ServiceManager is providing services that it manages (i.e. the provided
> services and completely managed by the manager - no release semantics).
>
> interface ServiceManager
> {
> Object lookup( String role ) throws ServiceException;
> boolean hasObject( String role );
> }
>
> 2. ServiceManager is providing services that must be release back to the
> manager to enable pooling. As before, ServiceReclaimer is seperated
> out because we need this for the selection interface.
>
> interface ServiceReclaimer
> {
> void release( Object object );
> void releaseAll( Object token );
> }
>
> interface ServiceResolver extends ServiceManager, ServiceReclaimer
> {
> Object checkout( String role ) throws ServiceException;
> Object checkout( String role, Object token ) throws
> ServiceException;
> }
To me, the main purpose of ServiceManager is to look up an object that
matches the specified by role, i.e. behavioral interface. It think it
should be possible for the client to use ServiceManager just by knowing
the role. Having both "lookup" and "checkout" means that the client must
know something about the implementation the object, i.e. whether is
needs to be checked out and released. Semantically, this is one step
away from forcing the client to check whether "service instanceof
ThreadSafe", which IMO should not be the concern of the client.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
> > I was about to ask you how you would handle the selection among
> > several components for a role where some components are thread-safe
> > and some poolable: Do you pool the selectors or do you select among
> > several maybe-pools? But the ServiceChooser interface does that,
> > albeit in a very ugly way (pools everything).
>
> Firstly, I'm not recommending the simplification of interfaces such that
> situation could occur. Your example case is a good example of the
> conflicts
> that
> can be introduced when mixing concerns. The approach I have taken is that
> the client uses a manager to get the selection provider. If the selection
> provider is an instance of SelectionChooser, the client is now
> aware of its
> obligations concerning release of pooled resources. Code is therefore
> required to meet those responsibilities.
Right. And then we are back into having to explicitly test for poolable
components when retrieving them. Which is a step backwards.
It means that I have to do this:
Object component = manager.lookup (role);
if (component instanceof ServiceChooser) {
realComponent = ((ServiceChooser) component).checkout (...);
}
instead of just looking up the component.
> > Plus the lifestyle interfaces for the above.
>
> Small correction - "lifecycle interface" (singular). The interfaces as
> presented in the response resolved the issue of multiple composition
> mechanisms by requiring that a client that is using pooled resources
> narrow to an interface that supports pooling (hence the separation of
> the ServiceReclaimer interface).
And that is bad. If every lookup must be followed by a test-for-poolable
then that code should belong in the lookup method.
> Which bit is too much?
Too much repetitive code, too many interfaces, too much responsibility
shifted to the client.
> > My proposal is:
> >
> > interface ServiceManager {
> > public Object lookup (String role);
> > public Object lookup (String role, Object policy);
> > public void release (Object component);
> > }
> >
> > interface ServiceSelector {
> > public Object select (Object policy);
> > }
> >
> > interface ServiceHandler {
> > public Object lookup ();
> > public Object release ();
> > }
> >
> > Does everything you need:
> >
> > ServiceManager:
> >
> > public Object lookup (String role);
> > Looks up a role.
>
> But more correctly, you should add that the semantics "requires" that the
> client release this service even if the manager doesn't not need to be
> notified of the release.
Yes. This is to provide a unified interface for both poolable and
non-poolable
components.
> > public Object lookup (String role, Object policy);
> > Looks up a role, and gives the policy object to the selector if any.
>
> This is a reasonable convenience operation provided that we totally ignore
> the entire thread concerning token based release of pooled resources.
I'll state my position regarding tokens now: They are good if we can fit
them
into the interface, but I can do just as well without them. All they provide
is a releaseAll method, and that is non-critical, and orthogonal to
what we are discussing now.
I could easily refit the interface to support tokens:
public Object lookup (Token token, String role);
public Object lookup (Token token, String role, Object policy);
public void releaseAll (Token token);
What I am concerned with is the use of the ServiceManager/Resolver
interface -
I want *one* way to obtain *any* service - pooled or not. I want
one method call, and I do not want to have to test for a ServiceChooser
to handle pooled components as a special case.
> > ServiceSelector:
> > Intended to be implemented by the client, to provide
> > selection policies for components. The selector
> > selects among several ServiceHandlers and calls lookup()
> > on the selected one.
>
> Can you clarify for me the comment "implemented by the client". My
> understanding is that a ServiceSelector is implemented by the
> provider. It
> takes as an input argument of an object that specifies the selection
> criteria,
> and based on that criteria, attempts to resolve an appropriate service. If
> the
> object were implemented by the client then we don't need pass via an
> interface
> for that behaviour (because it's in the client implementation).
Situation: You want to select component based on a Color object.
Solution: Create a class that implements ServiceSelector. Specify
this class (ColorSelector) in the configuration to the ServiceManager,
The need for an interface is becuase the ServiceManager will use
this class - not the client directly.
> > So the lookup is:
> >
> > ServiceManager ---- Picks among several, based on role ----> Selectors
> > *or* Handlers
>
> Do you mean that ServiceHandler *only* returns either a Selector or a
> Handler
> and explicitly not direct service - which would imply that the general
> return
> object is a Handler ? If this is correct, then yes, that simplifies the
> interfaces because pooled services get pushed down to handlers but at the
> same
> time it negates the simplicity of the current CM interface - lookup and
> forget
> about the manager.
No. I wasn't too clear on this, but this is what happens:
I call ServiceManager.lookup (role);
Object ServiceManager.lookup (String role) {
return lookup (role, null); // null policy means "gimme default", which if
there is no
// Selector, the single impl.
}
Object ServiceManager.lookup (String role, Object policy) {
Object instance = getMappingFor (role);
// component may be either a ServiceSelector or a ServiceHandler
ServiceHandler handler = null;
// Optionally select between several
if (instance instanceof ServiceSelector) {
handler = ((ServiceSelector) instance).select (policy);
} else {
handler = (ServiceHandler) instance;
}
Object component = handler.lookup ();
// So we can return it.
handlerMap.put (component, handler);
return component;
}
void ServiceManager.release (Object instance) {
ComponentHandler handler = (ComponentHandler) handlerMap.get (instance);
handler.release (instance);
handlerMap.remove (instance);
}
The simplicity I talk about is that there is no need to narrow the SM,
test for poolable components, etc. That is a huge advantage. With
tokens things are just as simple. I do not consider a 6 method interface
overloaded.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
> Stephen,
>
> I think this proposal is on a downward spiral.
I was actually thinking to myself that the proposal was getting reasonably
close to something that address the issues raised by Berin concerning tokens
and policy, that addressed your requirements for implicit release semantics,
cleared concerns expressed by Antti and Paulo concerning erroneous
conditions
when pixing in tokens, and finally, something that maintains a clear
seperation of concerns. It that consitures a downward spiral - the downward
in the right direction and spiralling just adds an interesting twist.
> The proliferation of interfaces is one indicator - we are moving
> towards a very find-grained interface with many opportunities
> for making mistakes instead of a simple interface.
In order to clarify the proposal, I have updated the interface specification
in jakarta-avalon/src/proposal/service to reflect the set of changes that
I'm comfortable with. This includes all of the above mentioned interests
but does not include resolution of convenience methods concerning lookup/
checkout with policy (for the reasons outlined in my reply to Antti).
Full javadoc is available at the following URL:
http://home.osm.net/doc/avalon/org/apache/avalon/framework/service/package-s
ummary.html
> I was about to ask you how you would handle the selection among
> several components for a role where some components are thread-safe
> and some poolable: Do you pool the selectors or do you select among
> several maybe-pools? But the ServiceChooser interface does that,
> albeit in a very ugly way (pools everything).
Firstly, I'm not recommending the simplification of interfaces such that
situation could occur. Your example case is a good example of the conflicts
that
can be introduced when mixing concerns. The approach I have taken is that
the client uses a manager to get the selection provider. If the selection
provider is an instance of SelectionChooser, the client is now aware of its
obligations concerning release of pooled resources. Code is therefore
required to meet those responsibilities.
> Now you have:
>
> - ServiceResolver
> - ServiceManager
> - ConvinienceServiceResolver
> - ConvinienceServiceManager
> - ServiceReclaimer
> - etc...
As noted in my email to Annti, I'm not proposing the convinience interface.
I don't believe this can specified cleanly if we embrase token based
parameters.
> Plus the lifestyle interfaces for the above.
Small correction - "lifecycle interface" (singular). The interfaces as
presented in the response resolved the issue of multiple composition
mechanisms by requiring that a client that is using pooled resources
narrow to an interface that supports pooling (hence the separation of
the ServiceReclaimer interface).
> So you have four ways of obtaining components, some of which require
> the calling code to be aware of implementation details such as
> poolable/non-poolable.
The interface describe 2 ways in which a service can be located. One
deals with non-pooled resources and other deals with potentially pooled
resources. In your case, you have a preference for an interface which
provides explicit support for pooling. Your implementations of a
ServiceResolver can leverage that fact that you can deal with both pooled
and non-pooled service in the same manner.
> This is just way too much.
Which bit is too much?
> My proposal is:
>
> interface ServiceManager {
> public Object lookup (String role);
> public Object lookup (String role, Object policy);
> public void release (Object component);
> }
>
> interface ServiceSelector {
> public Object select (Object policy);
> }
>
> interface ServiceHandler {
> public Object lookup ();
> public Object release ();
> }
>
> Does everything you need:
>
> ServiceManager:
>
> public Object lookup (String role);
> Looks up a role.
But more correctly, you should add that the semantics "requires" that the
client release this service even if the manager doesn't not need to be
notified
of the release.
> public Object lookup (String role, Object policy);
> Looks up a role, and gives the policy object to the selector if any.
This is a reasonable convenience operation provided that we totally ignore
the entire thread concerning token based release of pooled resources.
> public void release (Object component);
> Releases the component, no matter how it was obtained.
Which is also a convenience operation that ignores the complexities
introduced
by token based usage declaration. Keep in mind that I understand completely
the rationale for suggesting this - however, could you re-visit this
proposal
taking into account the token based release of services. If you do, you end
up adding yet another operation that has to evaluation of release object
against a service pool where the released object may not exist in the pool.
> ServiceSelector:
> Intended to be implemented by the client, to provide
> selection policies for components. The selector
> selects among several ServiceHandlers and calls lookup()
> on the selected one.
Can you clarify for me the comment "implemented by the client". My
understanding is that a ServiceSelector is implemented by the provider. It
takes as an input argument of an object that specifies the selection
criteria,
and based on that criteria, attempts to resolve an appropriate service. If
the
object were implemented by the client then we don't need pass via an
interface
for that behaviour (because it's in the client implementation).
> ServiceHandler:
> Handles lifecycle management for a service instance/instances.
> Most ServiceHandlers will do this based on Avalon marker interfaces -
> the default implementation will honor all such interfaces in framework.
> However, should a component require a specialized handler, this
> can be overridden in the configuration to the SM.
This is something new - so far in the proposal goes - I've included the
selection
semantics that basically mirror the existing framework object model. Based
on
my experience I haven't seen the necessity for non-standard handlers.
However,
if I considered a pooled resources as an object that required supplementary
handling (because of its implied release overhead), I guess in principal
that
this would eliminate the need for the ServiceResolver, ServiceReclaimer and
ServiceChooser interface (but my guess is that you didn't have this in
mind).
> So the lookup is:
>
> ServiceManager ---- Picks among several, based on role ----> Selectors
> *or* Handlers
Do you mean that ServiceHandler *only* returns either a Selector or a
Handler
and explicitly not direct service - which would imply that the general
return
object is a Handler ? If this is correct, then yes, that simplifies the
interfaces because pooled services get pushed down to handlers but at the
same
time it negates the simplicity of the current CM interface - lookup and
forget
about the manager.
> (optional step) Selector ---- selects among several,
> based on policy ----> Handlers
>
> Handlers manage lifecycle/lifestyle.
>
> And yes, you will have empty methods. There is no way getting around it.
A.K.A inconsistencies when other people who haven't been following this and
related threads attempt to implement something that is intended to work as
a pluggable framework component.
> Gains:
>
> - Unified way of obtaining services, irrespective of
> poolable/threadsafe.
+1
> - Unified way to do N-dimensional lookups (Selection)
And ignores the complexity of dealing with token based resolution.
> - Accomodates components that do not have Avalon lifecycle
> interfaces via
> custom handlers.
In my experience this is not needed. I'm dealing every day with this
scenario and I haven't come across a requirement for a handler (yes, I've
had to use a holder to bypass the Component restriction but a holder is not
a handler - holder don't provide additional behaviour).
> - Few interfaces with few methods.
Providing you ignore tokens. So lets put this on a level playing field.
Are
you ready to address token or not. If you saying that tokens don't matter -
then sure - things become simpler, but if doing a comparison, do the
comparison
so that your comparing apples with apples.
> - Easily understood contracts.
Simpler to look at - agreed. More precise - no.
Addressing the scope of the discussion - no. Perhaps it would be valuable
for
you to detail you opinions on the token subject. All of the proposals you
have
put forward here ignore that aspect and leverage their simplicity as
arguments
(which is could be considered as misleading!). No. if your out and out
opposed
to the idea of tokens, the say so - then we can try to clarify if token-less
interfaces would be preferred. If that's the case, then its a lot easier to
come up with simple interface.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Stephen,
I think this proposal is on a downward spiral.
The proliferation of interfaces is one indicator - we are moving
towards a very find-grained interface with many opportunities
for making mistakes instead of a simple interface.
I was about to ask you how you would handle the selection among
several components for a role where some components are thread-safe
and some poolable: Do you pool the selectors or do you select among
several maybe-pools? But the ServiceChooser interface does that,
albeit in a very ugly way (pools everything).
Now you have:
- ServiceResolver
- ServiceManager
- ConvinienceServiceResolver
- ConvinienceServiceManager
- ServiceReclaimer
- etc...
Plus the lifestyle interfaces for the above.
So you have four ways of obtaining components, some of which require
the calling code to be aware of implementation details such as
poolable/non-poolable.
This is just way too much.
My proposal is:
interface ServiceManager {
public Object lookup (String role);
public Object lookup (String role, Object policy);
public void release (Object component);
}
interface ServiceSelector {
public Object select (Object policy);
}
interface ServiceHandler {
public Object lookup ();
public Object release ();
}
Does everything you need:
ServiceManager:
public Object lookup (String role);
Looks up a role.
public Object lookup (String role, Object policy);
Looks up a role, and gives the policy object to the selector if any.
public void release (Object component);
Releases the component, no matter how it was obtained.
ServiceSelector:
Intended to be implemented by the client, to provide
selection policies for components. The selector
selects among several ServiceHandlers and calls lookup()
on the selected one.
ServiceHandler:
Handles lifecycle management for a service instance/instances.
Most ServiceHandlers will do this based on Avalon marker interfaces -
the default implementation will honor all such interfaces in framework.
However, should a component require a specialized handler, this
can be overridden in the configuration to the SM.
So the lookup is:
ServiceManager ---- Picks among several, based on role ----> Selectors
*or* Handlers
(optional step) Selector ---- selects among several,
based on policy ----> Handlers
Handlers manage lifecycle/lifestyle.
And yes, you will have empty methods. There is no way getting around it.
Gains:
- Unified way of obtaining services, irrespective of poolable/threadsafe.
- Unified way to do N-dimensional lookups (Selection)
- Accomodates components that do not have Avalon lifecycle interfaces via
custom handlers.
- Few interfaces with few methods.
- Easily understood contracts.
- Predictable results.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Antti:
I pretty much agree with all of the points you raised - in particular the
fact the introduction of two composition mechansisms is undesirable. I've
provided below a revision of the model that solves this. Changes are noted
in-line. If we generally agree on the this model - we can come back to the
question of convinience by building a composite interface from the model.
I've already tried to do that but ended up with something I felt
uncofortable (see details later in this message).
The entry point ...
interface Serviceable
{
public void service( ServiceManager manager ) throws ServiceException;
}
Ok, so far so good. In the CM discussions we have two distinct
usage models that have been discussed. Here is a slightly modified re-cut
of the manager and resolver interfaces (please note that I'm reverting
back to term "checkout" for service that should be returned to the manager
as distinct from lookup).
1. ServiceManager is providing services that it manages (i.e. the provided
services and completely managed by the manager - no release semantics).
interface ServiceManager
{
Object lookup( String role ) throws ServiceException;
boolean hasObject( String role );
}
2. ServiceManager is providing services that must be release back to the
manager to enable pooling. As before, ServiceReclaimer is seperated
out because we need this for the selection interface.
interface ServiceReclaimer
{
void release( Object object );
void releaseAll( Object token );
}
interface ServiceResolver extends ServiceManager, ServiceReclaimer
{
Object checkout( String role ) throws ServiceException;
Object checkout( String role, Object token ) throws
ServiceException;
}
Given the above - we have just eliminated an ambiguity concerning the lookup
operation. Lookup is now cleanly associated with services that do not
require
release whereas checkout would maintain internal state about service usage.
Relative to the conclusions derived from Leo's input, the difference in the
above is that checkout and release of an object requires narrowing the
manager
to a resolver. The improvement is that we eliminate the need for a
Resolvable
and the associated lifecycle implications.
The only thing missing now is the selection of a service based on a supplied
criteria. Before entering into the convenience question, I would like to
detail this interface based on an SOC priority.
As before, we have the two usage models:
1. selecting a service with supplied policy where no token is required
and no release semantics are implied
interface ServiceSelector
{
Object select( Object policy ) throws ServiceException;
boolean isSelectable( Object policy );
}
2. selecting a service that must be release back to a service pool
(not that "choose" replaces "select" under token based usage
interface ServiceChooser extends ServiceSelector, ServiceReclaimer
{
Object choose( Object token, Object policy ) throws
ServiceException;
}
Summary - using the above we have only one lifecycle operation to be
concerned
with (i.e. Serviceable) based on the presumption that the client is
narrowing
from ServiceManager to ServiceResolver as required. Secondly, the above
model
assumes that service selection is delegated. Given the above (which I think
is clean and consistent), the objective of a convinience interface is to
include
the select functionality in both the manager and resolver cases.
Antti Koivunen wrote:
>
> Stephen McConnell wrote:
> <skip/>
> >>>>
> >>>This principal is that selection (brought about by the introduction
> >>>of a policy argument) is something that can be isolated under a
> >>>separate ServiceSelector implementation. This means that the common
> >>>ServiceManager does not need to be polluted with selection semantics.
> >>>From an implementation perspective this is a really good thing because
> >>>we achieve isolation the behaviour (no empty methods).
>
> The semantics of such lookups (role+policy) are well defined and would
> not lead to empty methods. The behavior would be exactly the same as in
> ServiceSelector. How much effort would it actually take to implement
> something like this?
>
> void addService( String role, ServiceSelector selector );
Agreed - there isn't an "empty-method" issue here.
> >>>... The principal
> >>>is the you "lookup" the directory then apply "select" against the
> >>>directory that is returned.
>
> But why do we need the additional step? Including selection in
> ServiceManager would not change the principle.
An in-my-head fight between separation of concerns and convenience.
I want to see interfaces that clearly separate concerns and that can
be used to construct a convenience interface if needed. While incorporating
selection into service manager is relatively simple, the same is not true in
the case of token based methods.
interface ConvinienceServiceManager extends ServiceManager
{
Object select( String role, Object policy ) throws
ServiceException;
boolean isSelectable( String role, Object policy );
}
interface ConvinienceServiceResolver extends ServiceResolver
{
Object select( String role, Object policy ) throws
ServiceException;
boolean isSelectable( String role, Object policy );
Object choose( String role, Object token, Object policy ) throws
ServiceException;
void release( String role, Object object );
void releaseAll( String role, Object token );
}
My impression is that the ConvinienceServiceManager interface is
'understandable'
- however, the ConvinienceServiceResolver case is looking well and truly
overloaded.
Providing one without the other would be inconsistent. I remain convinced
that
separation of selector from the manager is a good thing.
> <skip/>
>
> > interface ServiceReclaimer
> > {
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > interface ServiceResolver extends ServiceManager, ServiceReclaimer
> > {
> > Object lookup( String role, Object token );
> > }
> >
> > interface PooledSelector extends ServiceSelector, ServiceReclaimer
> > {
> > Object select( Object token, Object policy );
> > }
>
> Let's look at the complete interfaces (show below).
>
> interface ServiceManager
> {
> Object lookup( String role );
> boolean hasService( String role );
> }
>
> interface ServiceResolver extends ServiceManager, ServiceReclaimer
> {
> boolean hasService( String role );
>
> Object lookup( String role );
> Object lookup( String role, Object token );
>
> void release( Object object );
> void releaseAll( Object token );
> }
>
> ServiceManager looks more like a ServiceResolver and vice versa. One of
> them just finds a service and the other one actually does some managing.
> Don't you think switching the names would better describe the components?
>
> I would not mix with-token and without-token operations. This would be
> less consistent and more difficult to implement.
I agree.
In the interfaces presented above I differentiated token based operations
using the method name "checkout". Does this properly address that issue?
> interface Serviceable
> {
> public void service( ServiceManager manager )
> throws ServiceException;
> }
>
> interface Resolvable
> {
> public void resolve( ServiceResolver resolver )
> throws ServiceException;
> }
>
> Let's say Project A uses ServiceResolver and Project B is determined to
> use ServiceManager. Project C would like to use components produced by
> both, and implement components that can be used by all projects. So,
> Project C's components would look something like the following:
>
> class ComponentC implements Serviceable, Resolvable
> {
> private ServiceManager manager;
>
> public void service( ServiceManager manager )
> {
> if (this.manager == null) {
> this.manager = manager;
> }
> }
>
> public void resolve( ServiceResolver resolver )
> {
> if (this.manager == null) {
> this.manager = resolver;
> }
> }
> }
This was bugging me as well. In principal I would like to just one
composition mechanism. The approach in the interfaces described at the
beginning of this email negate this requirement providing the client
narrows the supplied manager to a resolver if needed.
> Possible? Of course. The practice we'd like to promote? Not so sure.
> Also, LifecycleHelper and other similar classes would have to be aware
> of both Serviceable and Resolvable.
Agreed.
> Now, do you find the implications described above less severe than those
> of including all necessary functionality in ServiceManager? If so,
> please describe the practical issues caused by this.
I have addressed the issues you raised concerning (a) error prone inclusion
of Token in methods of the same name, and (b) elimination of the requirement
for
two composition approaches. I'm not happy with the resulting convenience
interfaces - but await further thoughts from yourself.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Son of ComponentManager
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stephen,
See the notes below.
Stephen McConnell wrote:
>
<skip/>
>>>>
>>>This principal is that selection (brought about by the introduction
>>>of a policy argument) is something that can be isolated under a
>>>separate ServiceSelector implementation. This means that the common
>>>ServiceManager does not need to be polluted with selection semantics.
>>>>From an implementation perspective this is a really good thing because
>>>we achieve isolation the behaviour (no empty methods).
The semantics of such lookups (role+policy) are well defined and would
not lead to empty methods. The behavior would be exactly the same as in
ServiceSelector. How much effort would it actually take to implement
something like this?
void addService( String role, ServiceSelector selector );
>>>... The principal
>>>is the you "lookup" the directory then apply "select" against the
>>>directory that is returned.
But why do we need the additional step? Including selection in
ServiceManager would not change the principle.
<skip/>
> interface ServiceReclaimer
> {
> void release( Object object );
> void releaseAll( Object token );
> }
>
> interface ServiceResolver extends ServiceManager, ServiceReclaimer
> {
> Object lookup( String role, Object token );
> }
>
> interface PooledSelector extends ServiceSelector, ServiceReclaimer
> {
> Object select( Object token, Object policy );
> }
Let's look at the complete interfaces (show below).
interface ServiceManager
{
Object lookup( String role );
boolean hasService( String role );
}
interface ServiceResolver extends ServiceManager, ServiceReclaimer
{
boolean hasService( String role );
Object lookup( String role );
Object lookup( String role, Object token );
void release( Object object );
void releaseAll( Object token );
}
ServiceManager looks more like a ServiceResolver and vice versa. One of
them just finds a service and the other one actually does some managing.
Don't you think switching the names would better describe the components?
I would not mix with-token and without-token operations. This would be
less consistent and more difficult to implement.
interface Serviceable
{
public void service( ServiceManager manager )
throws ServiceException;
}
interface Resolvable
{
public void resolve( ServiceResolver resolver )
throws ServiceException;
}
Let's say Project A uses ServiceResolver and Project B is determined to
use ServiceManager. Project C would like to use components produced by
both, and implement components that can be used by all projects. So,
Project C's components would look something like the following:
class ComponentC implements Serviceable, Resolvable
{
private ServiceManager manager;
public void service( ServiceManager manager )
{
if (this.manager == null) {
this.manager = manager;
}
}
public void resolve( ServiceResolver resolver )
{
if (this.manager == null) {
this.manager = resolver;
}
}
}
Possible? Of course. The practice we'd like to promote? Not so sure.
Also, LifecycleHelper and other similar classes would have to be aware
of both Serviceable and Resolvable.
Now, do you find the implications described above less severe than those
of including all necessary functionality in ServiceManager? If so,
please describe the practical issues caused by this.
(: A ;)
--
Antti Koivunen (Mr.) <an...@users.sf.net>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Sunday, 17 February, 2002 19:30
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > >
> > > Where does the policy object in PooledSelector come from when a
> > > lookup is done through a ServiceResolver? Isn't it necessary to have:
> > >
> > > interface ServiceResolver extends ServiceManager
> > > {
> > > Object lookup( String role );
> > > Object lookup( Object token, String role );
> > >
> > > Object lookup( String role, Object policy );
> > > Object lookup( Object token, String role, Object policy );
> > >
> > > void release( Object object );
> > > void releaseAll( Object token );
> > > }
> > >
> > > where the policy object is passed along to the selector if present?
> >
> > This principal is that selection (brought about by the introduction
> > of a policy argument) is something that can be isolated under a
> > separate ServiceSelector implementation. This means that the common
> > ServiceManager does not need to be polluted with selection semantics.
> > From an implementation perspective this is a really good thing because
> > we achieve isolation the behaviour (no empty methods). A selector
> > implementation can then apply local policy combined with supplied
> > policy to do the selection of an appropriate service. The principal
> > is the you "lookup" the directory then apply "select" against the
> > directory that is returned.
>
> OK. So in the cases where a lookup returns a ServiceSelector
> (and not a PoolableSelector), you get a ServiceSelector back,
> much like you get a ComponentSelector back in the current
> Avalon framework?
Yes.
> I am quite tempted by Berin's Query object approach to this, as well
> as letting the ServiceResolver do the lookup + select in one step.
> Rationale for this is:
>
> - When you lookup a service through the lookup method,
> you return it through the release method.
>
> - When looking up through a selector, you get the service from
> the selector, but return it via the resolver.
This break islolation (which is a fault in the current proposal).
What whould be more correct is that the source of provision is the
source of redemtion. I think that was already raised in antother
thread .. basically ServiceResolver and PooledSelector should
inherit from a common interface enabling redemption - e.g.
ServiceReclaimer.
interface ServiceReclaimer
{
void release( Object object );
void releaseAll( Object token );
}
interface ServiceResolver extends ServiceManager, ServiceReclaimer
{
Object lookup( String role, Object token );
}
interface PooledSelector extends ServiceSelector, ServiceReclaimer
{
Object select( Object token, Object policy );
}
This effectively eliminates the obligation for a service resolver to
know about a selection implementation. The selection implementation
is now free to release service in any way it see fit - potentially
independently of the resolver.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > Where does the policy object in PooledSelector come from when a
> > lookup is done through a ServiceResolver? Isn't it necessary to have:
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( Object token, String role );
> >
> > Object lookup( String role, Object policy );
> > Object lookup( Object token, String role, Object policy );
> >
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > where the policy object is passed along to the selector if present?
>
> This principal is that selection (brought about by the introduction
> of a policy argument) is something that can be isolated under a separate
> ServiceSelector implementation. This means that the common ServiceManager
> does not need to be polluted with selection semantics. From an
> implementation perspective this is a really good thing because we achieve
> isolation the behaviour (no empty methods). A selector implementation can
> then apply local policy combined with supplied policy to do the selection
> of an appropriate service. The principal is the you "lookup" the
> directory
> then apply "select" against the directory that is returned.
OK. So in the cases where a lookup returns a ServiceSelector
(and not a PoolableSelector), you get a ServiceSelector back, much like you
get a ComponentSelector back in the current Avalon framework?
I am quite tempted by Berin's Query object approach to this, as well
as letting the ServiceResolver do the lookup + select in one step.
Rationale for this is:
- When you lookup a service through the lookup method,
you return it through the release method.
- When looking up through a selector, you get the service from
the selector, but return it via the resolver.
Allowing the ServiceResolver to accept the key for the selector
would make it easier - you return stuff to the thing you got it
from. Plus, you get a more unified interface. All lookups,
through pools or n-dimensional selectors, are done through
a single interface.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Sunday, 17 February, 2002 18:26
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > Here is consolidation of the interfaces based on a logical extrapolation
> > of the conclusions reached under this thread:
> >
> > interface Serviceable
> > {
> > public void service( ServiceManager manager ) throws
> > ServiceException;
> > }
> >
> > interface ServiceManager
> > {
> > Object lookup( String role );
> > boolean hasService( String role );
> > }
> >
> > interface ServiceSelector
> > {
> > Object select( Object policy );
> > boolean isSelectable( Object policy );
> > }
> >
> > interface ServiceResolver extends ServiceManager
> > {
> > Object lookup( String role, Object token );
> > void release( Object object );
> > void releaseAll( Object token );
> > }
> >
> > interface PooledSelector extends ServiceSelector
> > {
> > Object select( Object token, Object policy );
> > }
> >
> > Over to you.
>
> Got the correction:
>
> interface Resolvable {
> public void resolve( ServiceResolver resolver ) throws
> ExceptionThrownWhenLookupFails;
> }
>
> Where does the policy object in PooledSelector come from when a lookup is
> done through a ServiceResolver? Isn't it necessary to have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role );
> Object lookup( Object token, String role );
>
> Object lookup( String role, Object policy );
> Object lookup( Object token, String role, Object policy );
>
> void release( Object object );
> void releaseAll( Object token );
> }
>
> where the policy object is passed along to the selector if present?
This principal is that selection (brought about by the introduction
of a policy argument) is something that can be isolated under a separate
ServiceSelector implementation. This means that the common ServiceManager
does not need to be polluted with selection semantics. From an
implementation perspective this is a really good thing because we achieve
isolation the behaviour (no empty methods). A selector implementation can
then apply local policy combined with supplied policy to do the selection
of an appropriate service. The principal is the you "lookup" the directory
then apply "select" against the directory that is returned.
> Before I go and vote for this one, I would also like to hear more
> about Peter's release-less version. If that one works, we could have:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object policy );
> }
>
> which is much cleaner. But it requires some other changes to the way we
> write components. See:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
>
> and my response:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
>
Agreed.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Here is consolidation of the interfaces based on a logical extrapolation
> of the conclusions reached under this thread:
>
> interface Serviceable
> {
> public void service( ServiceManager manager ) throws
> ServiceException;
> }
>
> interface ServiceManager
> {
> Object lookup( String role );
> boolean hasService( String role );
> }
>
> interface ServiceSelector
> {
> Object select( Object policy );
> boolean isSelectable( Object policy );
> }
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup( String role, Object token );
> void release( Object object );
> void releaseAll( Object token );
> }
>
> interface PooledSelector extends ServiceSelector
> {
> Object select( Object token, Object policy );
> }
>
> Over to you.
Got the correction:
interface Resolvable {
public void resolve( ServiceResolver resolver ) throws
ExceptionThrownWhenLookupFails;
}
Where does the policy object in PooledSelector come from when a lookup is
done through a ServiceResolver? Isn't it necessary to have:
interface ServiceResolver extends ServiceManager
{
Object lookup( String role );
Object lookup( Object token, String role );
Object lookup( String role, Object policy );
Object lookup( Object token, String role, Object policy );
void release( Object object );
void releaseAll( Object token );
}
where the policy object is passed along to the selector if present?
Before I go and vote for this one, I would also like to hear more
about Peter's release-less version. If that one works, we could have:
interface ServiceResolver extends ServiceManager
{
Object lookup( String role, Object policy );
}
which is much cleaner. But it requires some other changes to the way we
write
components. See:
http://marc.theaimsgroup.com/?l=avalon-dev&m=101392754607827&w=2
and my response:
http://marc.theaimsgroup.com/?l=avalon-dev&m=101395308809276&w=2
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
[snip]
> The question is then: Given a ServiceResolver that provides a
> unified way of obtaining services irrespective of whether they are
> pooled or not, what use is there for ServiceManager?
Because an implementation of ServiceManager is not polluted with
operations against which it has not semantics. Specifically, all
operations defined under ServiceManager are well defined - no ambiguity.
ServiceResolver captures semantics of pooled services without ambiguity.
So the up-side is that the interfaces are cleaner and the object mode is
consistent. The down-side is that a lifecycle pipeline needs to be aware
of the additional ServiceResolver interface. For me the up-side
significantly outweighs the downside.
Here is consolidation of the interfaces based on a logical extrapolation
of the conclusions reached under this thread:
interface Serviceable
{
public void service( ServiceManager manager ) throws ServiceException;
}
interface ServiceManager
{
Object lookup( String role );
boolean hasService( String role );
}
interface ServiceSelector
{
Object select( Object policy );
boolean isSelectable( Object policy );
}
interface Resolvable extends Serviceable{};
interface ServiceResolver extends ServiceManager
{
Object lookup( String role, Object token );
void release( Object object );
void releaseAll( Object token );
}
interface PooledSelector extends ServiceSelector
{
Object select( Object token, Object policy );
}
Over to you.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
> >
> > > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > >
> > > Based on the ServiceManager/ServicePool interfaces as presented
> > > in 06099, I think you would need a higher level abstraction that
> > > aggregates the two concerns. For example:
> > >
> > > interface ServiceResolver extends ServiceManager, ServicePool {}
> > > interface Resolvable extends Serviceable
> > > {
> > > public void resolve( ServiceResolver resolver );
> > > }
>
> I've made a mistake here concerning inheritance of ServicePool.
> ServicePool parameters assume the role is already established
> so my suggestion is invalid unless pool interfaces included the
> role argument. A corrected spec of ServiceResolver in included
> below.
>
> > I still have one issue with this: ServicePool uses "checkout" while
> > ServiceManager uses "lookup", leading to different code and semantics
> > for poolable/non-poolable components.
> >
> > However, if:
> >
> > interface ServiceResolver {
> > Object lookup (String role);
> > void release (Object service);
> > }
> >
> > in order to get the same code/semantics for poolable/non-poolable
> > components, then we're back to the old CM interface.
> >
> > How would you solve this?
>
> This suggests that poolable services are resolvable without a token.
Two cases:
1) Allow the client to release multiple components with a single call.
In this case you need a token. The ServiceResolver maps tokens ->
sets of components, and when you do a release(token), it releases
all components mapped to that token.
2) Only allow release of a single component at a time. No token is needed.
The object obtained in lookup() is used in the call to release().
So, yes, poolable services are resolvable without a token. But then
you can not do a releaseAll or equivalent.
> I really need you guys to clarify this for me because according to
> all of the discussions so far, you would need something like:
>
> interface ServiceResolver extends ServiceManager
> {
> Object lookup (String role, Object token );
> void release( Object object );
> }
>
> The above interface explicitly assumes that lookup( String role ) is a
> valid and semantically relevant operation for poolable services.
So for me this is workable:
interface ServiceResolver extends ServiceManager
{
void release( Object object );
}
This interface:
interface ServiceResolver extends ServiceManager
{
Object lookup (String role, Object token );
void release( Object object );
}
is workable, provided that:
void release( Object object ) is defined as follows:
void release( Object object ) {
if (object is a token that was passed to lookup(role, token))
{
release all services obtained with this token
}
else // In this case, object is a service obtained via lookup(role) or
lookup(role, token)
{
release just this service. If a token maps to this service,
remove the service from the token.
}
}
But I would want:
interface ServiceResolver extends ServiceManager
{
Object lookup (String role, Object token );
void release( Object object );
void releaseAll( Object token );
}
So you have lookup(role)/release(object) and
lookup(role,token)/releaseAll(token).
> If it
> is, the Resolvable/ServiceResolver as described above is workable. Can
> you confirm ?
Confirmed (sorta) above.
The question is then: Given a ServiceResolver that provides a unified way of
obtaining services irrespective of whether they are pooled or not,
what use is there for ServiceManager?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > Based on the ServiceManager/ServicePool interfaces as presented
> > in 06099, I think you would need a higher level abstraction that
> > aggregates the two concerns. For example:
> >
> > interface ServiceResolver extends ServiceManager, ServicePool {}
> > interface Resolvable extends Serviceable
> > {
> > public void resolve( ServiceResolver resolver );
> > }
I've made a mistake here concerning inheritance of ServicePool.
ServicePool parameters assume the role is already established
so my suggestion is invalid unless pool interfaces included the
role argument. A corrected spec of ServiceResolver in included
below.
> I still have one issue with this: ServicePool uses "checkout" while
> ServiceManager uses "lookup", leading to different code and semantics
> for poolable/non-poolable components.
>
> However, if:
>
> interface ServiceResolver {
> Object lookup (String role);
> void release (Object service);
> }
>
> in order to get the same code/semantics for poolable/non-poolable
> components, then we're back to the old CM interface.
>
> How would you solve this?
This suggests that poolable services are resolvable without a token.
I really need you guys to clarify this for me because according to
all of the discussions so far, you would need something like:
interface ServiceResolver extends ServiceManager
{
Object lookup (String role, Object token );
void release( Object object );
}
The above interface explicitly assumes that lookup( String role ) is a
valid and semantically relevant operation for poolable services. If it
is, the Resolvable/ServiceResolver as described above is workable. Can
you confirm ?
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Based on the ServiceManager/ServicePool interfaces as presented in 06099,
> I think you would need a higher level abstraction that aggregates the two
> concerns. For example:
>
> interface ServiceResolver extends ServiceManager, ServicePool {}
> interface Resolvable extends Serviceable
> {
> public void resolve( ServiceResolver resolver );
> }
I still have one issue with this: ServicePool uses "checkout" while
ServiceManager
uses "lookup", leading to different code and semantics for
poolable/non-poolable
components.
However, if:
interface ServiceResolver {
Object lookup (String role);
void release (Object service);
}
in order to get the same code/semantics for poolable/non-poolable
components,
then we're back to the old CM interface.
How would you solve this?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Saturday, 16 February, 2002 19:25
> To: Avalon Developers List
> Subject: RE: Son of ComponentManager
>
>
>
>
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> >
> > Leo Sutic :
> > [snip]
> >
> > > If SM replaces CM in Avalon5, *all* code written for Avalon4 will
> > > break. Not just in a way that can be solved with a search and
> > > replace, but the code has to be re-engineered to detect poolable
> > > components, or do away with those.
> >
> > If we take ExcaliburComponentManager as an example, we can see that
> > the transitional impact of ServiceManager, ServiceSelector
> > and ServicePool is minimal. ExcaliburComponetManager is in effect
> > a generalisation of the managed and pooled cases. The only
> > modification required would be the narrowing of the parent manager
> > to a ServicePool before invoking release.
> >
> > Current Excalibur release implementation includes:
> >
> > m_parentManager.release(component);
> >
> > The SOC introduced in the proposal would result in:
> >
> > if( m_parentManager instanceof ServicePool )
> > ((ServicePool)m_parentManager).release(component);
>
> So if I have this code:
>
> MyService service = (MyService) manager.lookup( "MY-ROLE" );
>
> How do I go from a ThreadSafe MyService to a Pooled version without having
> to change my code to:
>
> ServicePool pool = (ServicePool) manager.lookup( "MY-POOL" );
> MyService service = pool.checkout( this );
> MyService service = pool.checkout( this, myCriteria ); // alternative
> pool.release( service );
> pool.releaseAll( this ); // alternative
> As you are going from a one-step lookup for non-pooled components to a
> two-step
> lookup for pooled ones.
>
> Also, how do I go from pooled to threadsafe implementations without having
> to change back?
>
Based on the ServiceManager/ServicePool interfaces as presented in 06099,
I think you would need a higher level abstraction that aggregates the two
concerns. For example:
interface ServiceResolver extends ServiceManager, ServicePool {}
interface Resolvable extends Serviceable
{
public void resolve( ServiceResolver resolver );
}
Now you have something equivalent to the current ComponentManager but
with a clean separation of the underlying concerns of the different the
different service lifecycle semantics. This would allow you to supply
your new feature as an implementation of ServiceResolver which would
reduce the impact of transitioning between service types. In fact this
would be relatively friendly towards existing implementation such as the
ExcaliburComponentManager.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic :
> [snip]
>
> > If SM replaces CM in Avalon5, *all* code written for Avalon4 will
> > break. Not just in a way that can be solved with a search and
> > replace, but the code has to be re-engineered to detect poolable
> > components, or do away with those.
>
> If we take ExcaliburComponentManager as an example, we can see that
> the transitional impact of ServiceManager, ServiceSelector
> and ServicePool is minimal. ExcaliburComponetManager is in effect
> a generalisation of the managed and pooled cases. The only
> modification required would be the narrowing of the parent manager
> to a ServicePool before invoking release.
>
> Current Excalibur release implementation includes:
>
> m_parentManager.release(component);
>
> The SOC introduced in the proposal would result in:
>
> if( m_parentManager instanceof ServicePool )
> ((ServicePool)m_parentManager).release(component);
So if I have this code:
MyService service = (MyService) manager.lookup( "MY-ROLE" );
How do I go from a ThreadSafe MyService to a Pooled version without having
to
change my code to:
ServicePool pool = (ServicePool) manager.lookup( "MY-POOL" );
MyService service = pool.checkout( this );
MyService service = pool.checkout( this, myCriteria ); // alternative
pool.release( service );
pool.releaseAll( this ); // alternative
As you are going from a one-step lookup for non-pooled components to a
two-step
lookup for pooled ones.
Also, how do I go from pooled to threadsafe implementations without having
to change back?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic :
[snip]
> If SM replaces CM in Avalon5, *all* code written for Avalon4 will
> break. Not just in a way that can be solved with a search and
> replace, but the code has to be re-engineered to detect poolable
> components, or do away with those.
If we take ExcaliburComponentManager as an example, we can see that
the transitional impact of ServiceManager, ServiceSelector
and ServicePool is minimal. ExcaliburComponetManager is in effect
a generalisation of the managed and pooled cases. The only
modification required would be the narrowing of the parent manager
to a ServicePool before invoking release.
Current Excalibur release implementation includes:
m_parentManager.release(component);
The SOC introduced in the proposal would result in:
if( m_parentManager instanceof ServicePool )
((ServicePool)m_parentManager).release(component);
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo:
>
> >
> > And then you can use om.lookup for objects and components.
> > Does this solve your immediate needs? That is, getting
> > something working NOW, with not too much crap for future
> > cleanups?
>
> Absolutely not!!!!!
Stephen,
well, you were not asked. Whether this fits with your idea of what should be
is utterly irrelevant.
Paul needs something ***now*** as in "right this second".
I have the impression that his development is ***blocked*** until he can
get non-Component classes out of a CM. If I am wrong, well - ignore the
solution and we'll hack away at the next-generation CM.
I am very well aware that the solution I proposed is very temporary,
and not a substitute at all for a proper solution that will be in
Avalon 5. Or 4.2. Or whatever.
But:
- It allows him to proceed with his project ***NOW***.
- It allows him to do what he wants with Avalon 4 ***NOW***.
- It can easily be upgraded to Avalon 5, or whenever the new interfaces
become available.
Whether it sucks in an architectural way is not even a consideration.
****** I know it does. ********
> Please go back and read the proposal.
> http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06099.html
I am well aware of the proposal, and since I consider it madness to
expect the client to be aware of poolable/threadsafe I am -1 on it.
The proposal, as given, is *more* than just a jettisoning of the Component
interface. If your proposal had just been "Component -> Object for
ServiceManager,
otherwise same contract as CM", I would have been +1 on it. But it is *much*
more.
It shifts responsibilities around in ways that I consider unacceptable.
If SM replaces CM in Avalon5, *all* code written for Avalon4 will break. Not
just
in a way that can be solved with a search and replace, but the code has to
be
re-engineered to detect poolable components, or do away with those.
> The solution is already there - you may want to sit around until
summertime
> contemplating the meaning of life but some of us have more pressing
agendas.
Stephen, I am well aware of pressing agendas. That is why I sent that
solution
to Paul. There is not enough time to get anything into Avalon proper.
The solution I gave is precisely for pressing agendas. If development
is blocked due to an API constraint, then a way must be found around that
constraint so development can proceed. Then, when the API has changed to
something that can be used without the kludges added before, remove kludges.
THAT is what my solution to Paul is about.
Every second, Paul & co. are basically idling. If they can get a kludge in
that allows them to proceed, is that not preferable to idling even if it
means that some changes will have to be made to the code afterwards -
changes that can easily be contained to a single abstract base class?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Stephen McConnell <mc...@apache.org>.
[BIG VERY OBJECTIONABLE & FRUSTRATING SNIP]
Leo:
>
> And then you can use om.lookup for objects and components.
> Does this solve your immediate needs? That is, getting
> something working NOW, with not too much crap for future
> cleanups?
Absolutely not!!!!!
I think Paul is going to have to resent that thing about
user requirements! What Paul wants, what I want, and what a bunch
of other people want is simply the following:
public MyClass implements Serviceable
{
public void service( ServiceManager manager )
{
Object object = manager.lookup("MY-SERVICE");
}
}
That's it - that all!
If someone wants a recyclable service all they need to do is:
public MyClass implements Serviceable
{
public void service( ServiceManager manager )
{
ServicePool pool = (ServicePool) manager.lookup("MY-POOL");
Object object = pool.checkout( this, "MY-SERVICE" );
pool.release( object );
}
}
It's that simple.
Please go back and read the proposal.
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06099.html
> Getting the next version may not be possible for
> a while, maybe by summer.
What possible justification!
The solution is already there - you may want to sit around until summertime
contemplating the meaning of life but some of us have more pressing agendas.
Some of us have to deal with the real world - a world where a component is
implemented as an Object - a world where not everything can be passed as
a Component. Please - go back, look at the proposal, keep yourself
constrained to the abstractions defined in the framework and if there
is a problem - please detail what your problem is.
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> package packagename;
>
> import org.apache.avalon.framework.component.Component;
> import org.apache.avalon.framework.component.ComponentException;
>
> public interface ObjectManager implements Component {
> public static void ROLE = "packagename.ObjectManager";
> public Object lookup (String role) throws ComponentException;
> }
>
> ----------------------------
>
> public class DefaultObjectManager implements ObjectManager, Composable,
> ThreadSafe {
>
> private ComponentManager manager = null;
>
> public void compose (ComponentManager manager) {
> this.manager = manager;
> }
>
> public Object lookup (String role) throws ComponentException {
> Component maybeWrapper = manager.lookup (role);
> if (maybeWrapper instanceof ComponentWrapper) {
> return ((ComponentWrapper) maybeWrapper).getObject ();
> } else {
> return maybeWrapper;
> }
> }
> }
>
Oops - for Avalon4 compatibility, must not forget:
public interface ObjectManager implements Component {
public static void ROLE = "packagename.ObjectManager";
public Object lookup (String role) throws ComponentException;
public void release (Object obj);
}
public class DefaultObjectManager implements ObjectManager, Composable,
ThreadSafe {
private ComponentManager manager = null;
public void compose (ComponentManager manager) {
this.manager = manager;
}
public Object lookup (String role) throws ComponentException {
Component maybeWrapper = manager.lookup (role);
if (maybeWrapper instanceof ComponentWrapper) {
return ((ComponentWrapper) maybeWrapper).getObject ();
} else {
return maybeWrapper;
}
}
public void release (Object object) {
if (object instanceof Component) {
manager.release ((Component) object);
}
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Son of ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Right - since the object you will lookup do not:
- Implement any Avalon lifestyle interfaces
- Are all threadsafe
- Will probably be added to the CM via addComponent calls
Here - patchy, but here *today* and does *not* break compatibility:
package packagename;
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.component.ComponentException;
public interface ObjectManager implements Component {
public static void ROLE = "packagename.ObjectManager";
public Object lookup (String role) throws ComponentException;
}
----------------------------
public class DefaultObjectManager implements ObjectManager, Composable,
ThreadSafe {
private ComponentManager manager = null;
public void compose (ComponentManager manager) {
this.manager = manager;
}
public Object lookup (String role) throws ComponentException {
Component maybeWrapper = manager.lookup (role);
if (maybeWrapper instanceof ComponentWrapper) {
return ((ComponentWrapper) maybeWrapper).getObject ();
} else {
return maybeWrapper;
}
}
}
----------------------------
public class ComponentWrapper implements Component, Configurable, ThreadSafe
{
private void Object object;
/**
* When using ComponentManager.addComponent
*/
public ComponentWrapper (Object object) {
this.object = object;
}
/**
* When using dynamic config. Useful?
*/
public void configure (Configuration config) throws
ConfigurationException {
try {
String wrappedClassName = config.getAttribute ("wrapped-class");
// ... make this.object an instance of wrappedClassName
} catch (Exception e) {
throw new ConfigurationException ("Could not instantiate wrapped
class.");
}
}
public Object getObject () {
return object;
}
}
----------------------------------------
Use the above like this:
public class MyComponent {
ObjectManager om = null;
public void compose (ComponentManager cm) throws ComponentException {
om = (ObjectManager) cm.lookup (ObjectManager.ROLE);
}
...
}
And then you can use om.lookup for objects and components.
Does this solve your immediate needs? That is, getting something working
NOW,
with not too much crap for future cleanups? Getting the next version may not
be possible for a while, maybe by summer.
(Summer of CM, of course.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>