On Sun, 8 Dec 2002 11:51 am, Peter Donald wrote: > > Do you think it would be useful for framwork to include a set of > > container-independent interfaces that cover some of the common ways that > > a component interacts with the container? > > In a word no. Interfaces that define methods to get at data are just > syntactic sugar. ie Whats the difference between > > 1. (String)context.get( "name.key" ); > 2. ((NameContext)context).getName(); > > and which would you prefer to use? (1) is easier to use (for both component > and container writers) and is more lightly coupled. So why do we need (2) ?
I agree, if it's just data we're talking about. However ... > If rather than data you are talking about services then I am not sure there > is any set of common services. I was wondering about services. In particular, services where the component requests that the container do something (where that "something" might, I guess, include handing over some data). That is, services that represent *the container itself*. By "common" services, I don't mean mandatory services that all containers must provide (of which there are probably none, as you say). What I mean is general-purpose services that are optional for a container to provide. Some possibilities (random thoughts): - Request that this component be stopped. - Create a proxy for this component, to hand off to other classes. - Locate a named classloader, etc. - For containers that support the notion of an application: - Locate an application resource. - Get information about the application (name, work-dir, etc). - Stop or restart the application. - Add or remove other components. Or sub-components. - Provide config for other components. - Provide data for other components. - Provide lifecycle extensions for other components. - Etc. Do you think these kinds of things would be good to define in framework? Ignore how they might be delivered to components, and how components declare dependencies, for the time being. > > Fair enough. Can you expand on this? How do you view MailetContext and > > ServletContext and EntityContext and friends in relation to Context and > > framework? > > XContext == Logger + Context + ServiceManager + Configuration/Parameters So is Context all the left-overs when Logger, ServiceManager, Configuration and Parameters have been extracted from XContext? Or is it something more significant? Or both? How do things like ServletConfig, or MailetConfig, or JNDI fit in? I assume they are part of a larger "XContext". -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
