> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> > 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.
> > 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?
> > I question the assertion
> > that the use of exists() as you propose is common java practice.
>
> java.lang.System returns null on a failed lookup
>
> java.util.Collection defines contains()
> java.awt.Container defines contains()
> java.util.Map defines containsKey() and returns null on a
> failed lookup
>
> java.lang.ClassLoader throws an exception on a failed lookup
> java.rmi.Registry throws an exception on a failed lookup
>
> javax.naming.Context defines no equavalent, but instead
> returns a new instance of itself on a failed lookup (not
> desirable behaviour!)
>
> 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.
> 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.
> there you go =)
>
> 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 think this mail sums up my views on Berin's proposal:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102352975913660&w=2
and this is why I do not think GC will do as a release() mechanism:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102363047028722&w=2
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
