avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: Context: usage recommendations?
Date Sat, 07 Dec 2002 23:58:15 GMT


It would be really useful to take a step back, and first figure out *what* a 
Context is, and *what* a ServiceManager.  Let's leave figuring out *how* to 
populate them until we know what they are.  We don't even know whether 
they're distinct things yet.

For example, the only real answer to the 'what is the difference between a 
context and a service manager?' question I've had so far is 'they're 
different because people think of them as different things'.  Which is fine, 
except no-one seems to be able to explain what the difference is, and why 
that difference is important enough to model in framework.

This is the crux of the matter.  Not whether it's *possible* to make the 
distinction, but whether it is *useful* to make the distinction.  Maybe it 
is, maybe it isn't.  (Hint: the distinction must be meaningful across *all* 
containers.  It can't be "well, it means this sometimes, and it means that at 
other times").

I also wonder how much of "people think of them as different things" is due to 
the fact that framework has a thing called "Context" and another thing called 
"ServiceManager", and "well .. um .. of course they're different things, 
otherwise they wouldn't be there".  In other words, are we trying to invent a 
meaning for Context because Context currently happens to be part of 

On Sun, 8 Dec 2002 05:42 am, Stephen McConnell wrote:

> A second interesting point is that the component author has 100% control
> over which services and locators are mapped to the context abstraction
> as opposed to the service abstraction.  

and later:

>  From here, the differentiating factor between contextualization and
> services phases is reduced to the ordered sequence in the lifecycle.

But service() is called immediately after contextualize().  How is it useful 
for the component writer to be able to map resources between these methods 
when they're called one-after-the-other?  Why bother?  Surely it would be 
easier for everyone involved to simply collapse those 2 methods?


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message