On Tue, 3 Dec 2002 08:44 am, Peter Donald wrote: > 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.
Could someone explain why the distinction between resources provided by the container and resources not provided by the container is important *to the component* itself? Why does it care? And if it does, why is it useful that the component should use one mechanism for looking up one group of resources, and a different mechanism for looking up the others (and presumably separate mechanisms to describe to the container the resources it is expecting)? Ignore the fact that some resources are passive, immutable 'data' and other resources are active 'services' - that's a separate distinction. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
