Peter, > On Tue, 3 Dec 2002 08:08, Peter M. Goldstein wrote: > > It also seems compatible with what seems to me to be the natural > > separation between Contextualizable and Serviceable. Context involves > > data and services that are uniquely owned by the container (i.e. for > > Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James > > Mailets, getPostmaster(), isLocalServer(String)). The essential > > distinction as I see it is that services should be user-defined and > > configured, while context-related items should be container-defined and > > not require configuration. Also, the services may include a > > configurable dependency chain, while Context implementations should be > > available before any services are loaded and should not have a > > configurable dependency chain. > > Thats essentially how it is defined now and how I think it should be.
Well, I'm glad you concur but I don't think there is a general consensus among the participants in Avalon-dev. I certainly don't see this definition (or anything like it) clearly elucidated in the docs. To me, this paragraph seems like a natural starting point from which to build such a consensus as to the proper responsibilities of Context and ServiceManager. > > The above definition is tightly tied to the nature of the container and > > the API it supports. Hence what is in the Context in a nested container > > might not naturally fall into the Context of its parent container. > > yep - and most likely the elements inside a nested containers context are > possibly defined by services that the parent containre offers. Absolutely. And the inner Context can provide a nice abstraction barrier that insulates one container from another. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
