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. > 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. -- Cheers, Peter Donald *------------------------------------------------------* | "Religion is what the common people see as true, the | | wise people see as false, and the rulers see as | | useful" --Seneca | *------------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
