Hello Berin!
BL> The purpose of the Context is to pass constants to the client.
Great :) I really did not know that!
Not even the "Developing with Apache Avalon" has tought me that
(maybe I have missed something?)
The yes, "kernel services" shouldn't be in the Context.
BTW, is "kernel services" the proper name for loggerManager, etc?
I've picked up this word combinatino somewhere on the list..
BL> .. there is some overlap between a Context and the ServiceManager,
BL> and in a future version of Avalon we _might_ merge the concepts.
Indid this nothing close to what I wanted (see bellow).
AT> And after all they are quite different from user services - these
AT> are system entities.
Here's really what I had in my mind when I said I would be more
comfortable with "kernel services" being fetched from the context:
I would like my componet-aka-nested-container be entirely
self-contained - I wont none of my child components ever
to lookup any component provided by my parent container,
but I still want my child components to use the standard
"kernel services".
The motivation for being self-contained is environment
independence and hence reliability.
If "kernel services" were fetched from the Context it would be a piece
of cake: I would override service like this:
public void service( final ServiceManager serviceManager )
{
m_serviceManager = new FortressServiceManager( this, null );
}
and I would be happy.
The convinience would come not from the fact that "kernel services"
are fetched from a Context, but from the fact that they are just
fetched _from a different place_, other then the place from where
"user space" services are fetched.
If "kernel" and "user space" services were fetched from different
places it would be very easy to block access to "user space" services
coming from outside my current container (to insure environment
independence and reliability) but to allow access to "kernel" services
coming from outside.
The motivation is the following:
self-contained nested container is boolet-proof reliable because
it does not need user space services provided from outside.
no matter what the overall configuartion of the system is
it will survive.
at the same time accessing "kernel services" coming from outside
does not compromise the reliablity because every environment is
expected to provide them all - even if misconfigured
(not too badly of course :-)
Resume: it would be _very nice_ to cut access to "user space"
services coming from outside the container but allow access to
"kernel" services coming from outside in a nested container.
This is how I understand being "self contained".
And fetching these services from different sources would
immensly help this task.
Admittedly, Context is not be the best vehicle to drive
this separation because of the conceptual reasons.
Are we about to introduce a new lifecycle interface? ;-)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
