avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [proposal] avalon 5 ComponentManager interface
Date Tue, 11 Jun 2002 08:21:17 GMT


> From: Leo Simons [mailto:leosimons@apache.org] 
>
> It is so funny to see one arguing for exceptions in one 
> place, then against them in another (and vice versa).
> 

Throwing Exceptions for exceptional circumstances?

> > > > 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.

It's not 2D - it is n-D. The Object may be anything - a Map or 
whatever. The reason I want String,Object is because we have
fixed one dimension to be an interface name. If we hadn't,
a lookup(Object) would do.

> > > 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.

That's what I meant, but maybe not what I wrote.
 
> > > 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?

Because you get an instant ComponentException instead of a 
NullPointerException later in the processing.

> > 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.

No. If you want to replace something that does A, B and C,
with something that only does A and B, you have to explain
how to do C or how you solve the problem that C was intended to
solve.

And you don't. Peter doesn't, and Berin doesn't either. Just a fond
hope that it is possible - but is it really, under the constraints
imposed by your proposed interface?

/LS


--
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