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:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 7:34 AM
> To: Avalon Developers List; [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> > 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:[EMAIL PROTECTED]]
> > > Sent: Sunday, February 17, 2002 6:26 PM
> > > To: Avalon Developers List
> > > Subject: RE: Son of ComponentManager
> > >
> > >
> > >
> > >
> > > > From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> > > >
> > > > 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:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
