avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Sun, 08 Dec 2002 05:21:28 GMT
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?


> 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".



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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message