On Sun, 8 Dec 2002 13:56, Adam Murdoch wrote: > 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.
You may want to check out the other service frameworks (HPs CSF, OSGi specifications, etc). Because the above are relatively widely accepted as features of service frameworks in one form or another. The more general form would be something like; - allow a component to set it's own state (which may result in component shutdown or suspending or deactivation or ...). - create proxies for this component and other object when passing to other clients. The proxy may be client-specifc. ie If passing to remote client would create a remote proxy while if passing to local client may create a local proxy. - access metadata about current components type - access metadata about current components instance - access metadata about current partition/application instance - access metadata about deployment unit that currently in (ie .sar/.war file) - access resources from deployment unit that currently in (ie getResourceAsStream) > - 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. The above are less widely used and fairly container specific. But most containsers that support this do it via a directory ala JNDI. A lot of what you are talking about (management) is ususally done via another management system that is othogonal to component concerns. > Do you think these kinds of things would be good to define in framework? eventually. Unfortunately no current Avalon container is comprehensive enough to define either set. Until we have seen the interface in action I don't think that there is any reason to commit to one at the framework level. > 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? mostly. > Or is it something more significant? It also contains "runtime" values - ie stuff that the user doesn't provide the component (either through configuration or assembly processes). > How do things like ServletConfig, or MailetConfig, Configuration/Parameters for component accessed via the XContext. > or JNDI fit in? JNDI is slightly different in that it is just an access API and different frameworks use it for different things. Many use them as just a ServiceManager but some also stuff in Avalon Context and Configuration stuff. > I > assume they are part of a larger "XContext". largely. -- Cheers, Peter Donald "Man's mind stretched to a new idea never goes back to its original dimensions." -Oliver Wendell Holmes -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
