[Avalon5] Context Consensus

[Leo Sutic <le...@inspireinfrastructure.com>]

All,

I split off the A5 parts of the Context discussion in order to move the A4 
part forward toward a proposal. This post contains some minor 
clarifications - mostly inclusion of Stephen's and Paul's comments on the 
previous summary.

                               -oOo-

What follows is a *very* brief overview of the ideas that have been shown 
on the list. There is no concensus on any of the below solutions.

LOCATORS

These unify all lookup operations. Much as a component can specify what 
services it depends on, it can specify what locators it requires. For 
example, a ServiceLocator or a SystemLocator. The locator is passed in in 
the contextualize() and service() methods, and the component can then cast 
the locator to any of the required interfaces before performing the lookup 
operations.

     void contextualize (Locator locator) {
         // Look up services...
         ServiceLocator sl = (ServiceLocator) locator;

         MyService ms = sl.lookup ("myservice");
         ...

         // Look up context info...
         SystemLocator sysLocator = (SystemLocator) locator;

         File workDir = sysLocator.locate ("avalon:work");
         ...
     }

The only difference between contextualize() and service() would then be the 
ordering in the lifecycle, as this would enable one to lookup services and 
context (what used to be) values at both points.

This solution has been somewhat abandoned in favor of the BIG NAMESPACE 
solution below.


BIG NAMESPACE

Another way - that also unifies all lookup services - is to have a big 
namespace and a Locator interface:

     interface Locator {
         public Object lookup (String key);
     }

where key can be (for example):

     service:myservice
     context:workDir
     jndi:java:/something
     urn:something:else

The namespace (service, context, jndi and urn in the example above) would 
then be connected to a pluggable namespace handler in the container.


STAGED CONTEXTS

This idea has a different context depending on the lifecycle stage:

     public void init (InitContext initContext) { ... };

     public void start (StartupContext startupContext) { ... };

     public void stop (StopContext stopContext) { ... };

     public void dispose (DisposeContext disposeContext) { ... };

(
   The obvious (to me at least) parallell is:

     InitContext -> Context
     StartupContext -> ServiceManager
)

Objections to this was raise don the grounds that it is confusing.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>