> > > All ComponentManagers should support hints, or none. We're
> > not making
> > > the developers any favors by introducing yet another "this should
> > > work, but then again it might not".
> >
> > I think it would be relatively simple to explain which
> > Containers make use of a ComponentManager that supports
> > hints, and which do not. ie "if you use hints, you can use
> > fortress but not phoenix".
> >
> > So what you say is "this works in this setup, but not in this one".
> >
> > Note that if the contract for hints says that the CM can
> > freely ignore them (as Berin proposes), that is a lot more
> > like "this should have an effect, but then again it might not".
>
> That's fine. If lookup(role,hint) -> lookup(role) in Phoenix, then
> that's fine. I think it limits the number of components that can
> work in Phoenix, but that's an issue with Phoenix. I just do not
> want an IllegalArgumentException back.
'kay. I'll be happy to keep disagreeing and not specify the exception (I
can still throw it in private =).
It is so funny to see one arguing for exceptions in one place, then
against them in another (and vice versa).
> > > Also, with just String hints, if you use a ServletRequest
> > as hint, you
> > > end up with:
> > >
> > > lookup (role, stringifyRequest (request))
> >
> > yes. Keeping the interface more simple/limited means that
> > complex use of the interface becomes more complex. This is a
> > choice; I'm all for keeping the CM simple. For complex uses,
> > there's JNDI, DAP, etc etc.
>
> I'm against it. If the framework is intended to make writing of
> containers easy - then I'd be with you. But when you can get
> complex use by the client as cheaply as this, then I think it
> makes sense to put it in. Complexity should, when possible, be moved
> from the client and into the framework - after all, using the
> framework to reduce the complexity in our own code is what this
> is all about, right?
good point. But still
lookupFunction( String e, Object key ) seems too complex. It doesn't
resemble a Map enough. What is it internally, conceptually? A
two-dimensional hash? Why does a directory need a two-dimensional hash?
I can see one-dimensional, and n-dimensional. I don't get the
two-dimensional.
> > Which of these is most desirable, when that which you are
> > looking up is _not_ guaranteed to exist?
>
> The exist() way of doing things. But the overwhelming use case is for
> composers to directly call lookup() for components they *need* as
> opposed to components that are optional - in which case they use
> if (hasComponent()) lookup(). And thus the Exception way of doing
> things is better.
Uh, I'm thinking the reverse: the overwhelming use case is for composer
to call lookup() for components they need, so they specify to the
container that these are required and the container guarantees they're
there or doesn't call compose() - so they do *not* use exists() there.
Where the component can be optionally present, its existence is not
guaranteed by contract.
> > if the lookup should never fail, neither if(exists()) nor
> > try{}/catch{}/finally{} should be necessary at all.
>
> *should* as opposed to *could*! A lookup failing is an exceptional
> case, and should be treated as such.
But when the container guarantees "if you configure me correctly, the
lookup will never fail", why should the component developer still check?
> > on the subject of release(): if a proposal for the CM needs
> > to include a proposal regarding resource management (as you
> > state), then you disagree with the statement that resource
> > management is not of concern to the CM?
>
> Since you are removing functionality from the CM, I want to know
> whether you are removing it from the system completely, or if
> an equivalent to release() will exist, just in another form.
I thought we'd keep these issues separate (and separate proposals), as
that is what they should be.
Anyway, I think the way forward here is for a pool to implement the same
interface as the component it pools, or be cast to the same role. ie the
XXXXManager setup discussed.
This can be optional though and does not need to be part of the core of
all cores -- the lifecycle contracts.
cheers,
- LSD (That Other Leo)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
