avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [VOTE] RE: ComponentManager interface
Date Thu, 14 Feb 2002 01:17:21 GMT
Since the ServiceManager has a release() method, I guess that
services might not be Thread Safe???

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Thursday, February 14, 2002 2:11 AM
> To: Avalon Developers List
> Subject: RE: [VOTE] RE: ComponentManager interface
>
>
> > My observations of the current CM/CS is that in a perfect world,
> > we would only need the CM.  However, due to the complexities of
> > the real...
>
> I think that one of the differences is when you start using a
> token to free resources, which does not make sense for a Service,
> assuming that a service is Thread Safe and you just get to use it.
>
> So, if for services you would always have (although I still do
> not like these keys):
>
>   interface ServiceManager
>   {
>        Object lookup( String role );
>        Object lookup( String role, Parameters attributes );
>        void release( Object component );
>   }
>
> for a ComponentManager you could have:
>
>   interface ComponentManager
>   {
>        Object lookup( Object token, String role );
>        Object lookup( Object token, String role, Parameters attributes );
>        void release( Object component );
>        void releaseAll( Object token );
>   }
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, February 13, 2002 5:17 PM
> > To: Avalon Developers List
> > Subject: Re: [VOTE] RE: ComponentManager interface
> >
> >
> > Stephen McConnell wrote:
> > > Berin:
> > >
> > > Paul's vote on the ComponentManager interface proposal brings
> > > the number of +1 votes to 3, sufficient to go ahead with the
> > > ServiceManager proposal. Your reply on the initial request for
> > > vote was somewhat unclear with respect your position. If I
> > > understand correctly, you stated that in principal you would
> > > be -1 on anything not linked to Avalon 5.0.  As the proposal
> > > is not linked to Avalon 5.0, can you clarify for me if your
> > > message should be counted as a veto.  If not, I'll go ahead
> > > a commit the proposed service package this afternoon.
> > >
> > > Cheers, Steve.
> >
> >
> > :/
> >
> > I thought you could tell due to the fact that I was presenting the
> > Resolver package as an alternative that I haven't moved to +1 yet.
> >
> > I want to eventually add in a Query object ability--so we have two
> > options.
> >
> > 1) The ServiceManager stays as is with the change that the key lookup
> >     is an Object instead of String (String is common case, but allows
> >     for Query object enhancement later).
> >
> > 2) The ServiceManager has two methods: one String, and one Query object
> >
> >
> > Due to all the feedback, the Query object would be simplified to one
> > key and attributes.
> >
> > Another alternative to the whole explicit Query object is the following:
> >
> > interface ServiceManager
> > {
> >      Object lookup( String role );
> >      Object lookup( String role, Parameters attributes );
> >      void release( Object component );
> > }
> >
> > This way, we can reasonably handle default Lookup, and have no need for
> > the ComponentSelector equivalent.
> >
> > My observations of the current CM/CS is that in a perfect world,
> > we would only need the CM.  However, due to the complexities of the real
> > world, we need to address a specific configuration of a Component.  The
> > ComponentSelector was introduced to satisfy that goal.  However it is
> > terribly clumsy to have to do two levels of lookup.
> >
> > Please post your thoughts.
> >
> > If we introduce this change, we won't be able to add the extra
> > functionality
> > later for the Query object.
> >
> >
> > --
> >
> > "They that give up essential liberty to obtain a little temporary safety
> >   deserve neither liberty nor safety."
> >                  - Benjamin Franklin
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:avalon-dev-help@jakarta.apache.org>


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


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


Mime
View raw message