On Sat, 22 Feb 2003 03:13, [EMAIL PROTECTED] wrote:
> Quoting Jason van Zyl <[EMAIL PROTECTED]>:
> > On Thu, 2003-02-20 at 06:18, Peter Donald wrote:
> > > I would highly recomend that you don't use *Selectors. They were an
> >
> > ugly hack
> >
> > > put into place ages ago that I think most people now regret. Hopefully
> >
> > post
> >
> > > Fortress release we can start the process of deprecating them.
> >
> > Damn! :-)
> >
> > I added something like lookup(role, id) in Plexus and then from many
> > requests we put Selectors in to be compliant and now you want to get
> > rid
> > of them! :-) I argued they sucked because I figured that you could look
> > up any component using lookup(role,id) and use any logic you wanted to
> > select an id. Same idea as a selector but it's not baked into the
> > container.
>
> I can't understand why this design is bad... Can someone explain me ??? The
> general contract of ServiceSelector is that it returns the corresponding
> instance given a policy object.

yep. The problem is that it is a general interface that tries to be everything 
to everyone. It is generally considered better form to have a interface 
specific to resource type. ie

interface FooManager
{
  Foo getFoo( String param1, int param2 ); 
  void releaseFoo( Foo foo );
}

> But this does not answer my initial question that is :
> How do i instanciate the objects i must return without calling
> ContainerUtil methods directly ?
> This is because i should not know what lifecycle do implement my selected
> objects.

Essentially there is no way to do this nicely. There have been a number of 
different proposals for this but as yet there has been no decent solution and 
no solution that has got widespread adoption.

-- 
Cheers,

Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we 
cannot dodge the consequences of dodging our 
responsibilities." -Josiah Stamp 
--------------------------------------------------- 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to