avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [SUMMARY] Context Concensus
Date Tue, 10 Dec 2002 03:12:55 GMT

Leo Sutic wrote:

> All,
> I believe we had a very productive discussion on the definition of a 
> Context. Berin was right, though, in putting a hold on the 
> discussions. It was about time we got that resolution out the door, 
> given all the work that had gone into it.
> OK, now back to Contexts... since the vote regarding the PMC voting 
> procedure is in full swing, I want to use the pause in Context 
> discussion for a short recap and reflection.

Its a good recap.

I'm made a few comments in-line which are more a case of clarifying 
things and notes relating to issues that I think need to be addressed.

>                               -oOo-
> I'd like to summarize shortly the views and proposals that have been 
> put forth, trying to note any equivalence between the proposals and 
> point out where they differ, as well as trying to sort the 
> proposals/views under Avalon4 or Avalon5. For example, Stephen's 
> Locators and Noel's really-big-namespace are interesting ideas, but 
> definitely something for A5. I don't want the ideas to be thrown out 
> but on the other hand it must be understood that these things more 
> deal with a new and better Context, instead of the Context as it is 
> currently being used.

So far there is nothing that has been discussed that would be 
incompatible with released 4.1 Avalon components.  However, it is fair 
to say that to leverage the notions of locators and context domains, a 
developer would require A5 support - in particular interfaces on the 
container side, and standard meta-related resources.

> Finally, before I start, I like anyone who feels that their views are 
> being misrepresented here to post a correction. I think there is much 
> more common ground here than what is generally known.
>                               -oOo-
>                              AVALON 4
> There appear to be consensus on the Context being a read-only map of 
> values with defined types. For example, there is concensus that a 
> component should be able to request that they key "avalon:work" maps 
> to a File specifying the work directory.
> As for accessing those values, there are two approaches:
>  1) File workDir = (File) context.get( "avalon:work" );
>  2) File workDir = ((WorkDirectoryContext) context).getWorkDirectory();
> There appear to be concensus that (1) is, if not preferred, then at 
> least acceptable by everyone. I know of none who actively opposes such 
> usage.
> The context requirements are specified on a type level. That, each 
> component class would have an associated descriptor with what context 
> keys are expected, what value type it expects, etc. The above would be 
> specified as:
>     <entry key="avalon:work" type="java.io.File"/>
> optionally, with name remapping:
>     <entry key="workdir" intent="avalon:work" type="java.io.File"/>
> The actual DTD for this, as well as the way of creating and storing 
> such data varies (XDoclet generated XML, attributes embedded in the 
> .class file, etc.). However, there is concensus that the data itself 
> should be represented in *some* form. All proposals seem to have a 
> similar set of data elements: A key, a canonical key (avalon:work), 
> and a type specifier.

While a agree that the above reflects the current status, I would like 
to add a point here which is relavant to the excalibur/info and 
avalon/meta packages.

Basically, I think there is something wrong with both.

Consider the following current approach used in context declarations:

   <context type="SomeContextInterface">
     <entry key="map" type="java.io.Map"/>

There are two inconsitencies here.  Firstly, the declaration is defining 
a context obect that can be narrowed to SomeContextInterface, which is 
presumable specificed somewhere.  Secondly, we have a single context 
entry declaration with the keyname "map".  Is there a relationsh between 
the entry declarations and the interface? Are the entries part of the 
SomeContextInterface or are they supplimentary?  Are context entries 
that are not part of a context domain implied by a type considered as 
coexistant context domain?  

The current specification seems to me to be mixing concerns and leaves 
to many quetions open to the interpritation of a container author. I 
think this and other meta issues should be cleaned up as part of the 
work on A5.

> There is not concensus on whether the Context should have any active 
> operations. Stephen and Berin, for example, advocates that any active 
> operations should be exposed via the ServiceManager, and that the 
> Context should only be used to fetch data. (Note: By active 
> operations, I mean for example requestShutdown().)
> Others point to the Phoenix BlockContext interface.
> However, there is concensus that a component should be able to specify 
> any interface that it should be able to cast the context to. That is, 
> for every interface T,
>     public void contextualize (Context context) {
>         T myContext = (T) context;
>     }
> the component should be able to declare that it expects to cast the 
> context to a T. (For a less abstract example, replace T with 
> BlockContext.)
> This implies that the context must have all methods present in the T 
> interface.

All all keyed values implied by the interface.

> There is concensus that a method of specifying a context interface is 
> needed in order to specify the Phoenix BlockContext (whether it is 
> architecturally correct is another thing, and there's not concensus 
> here). (This is also not the only conceivable way of specifying what 
> methods is expected in the context, but this appear to be the one that 
> there is some concensus at least as to it being a sensible way of 
> doing it.)
> Regarding portability there is concensus that:
>  + For data, there should be a canonical set of context keys supported 
> by all containers (possibly different depending on Avalon ME, SE, EE 
> profiles).
>  + For data, there is also consensus that the more entries a component 
> requires, the less likely it is to be portable, and that this is 
> acceptable. That is, it is OK for a Avalon EE container to supply more 
> keys that an Avalon ME container. The tradeoff is: More requirements 
> -> less portability, and it is concensus that this is acceptable, 
> given clear guidelines on supported keys in different containers.
>  + For operations, there is concensus that operations *may* be 
> provided via the context. There is also concensus that this is a much 
> more limiting requirement, but given the usual tradeoffs and the 
> presence of clear guidelines, it is expected to be manageable, 
> although not recommended for portability reasons.
>                               -oOo-
>                              AVALON 5
> What follows is a *very* brief overview of the ideas that have been 
> shown on the list.
> 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");
>         ...
>     }

This reflects the emails we both exchanged and the discussion about 
multi-interface proxy solutions/disavantages.  My current thinking is 
that this is overly complex and that if you combine the context domain 
seperation notions from Noel with a single interface linked locator 
model, you have something much more robust.  In terms of the above, the 
difference is that the narrowing ability woudl be restricted to a single 
interface heirachy and that access to subsidiary context domains would 
be via specific keys or convinience operations exposed by the supplied 

Cheers, Steve.

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


Stephen J. McConnell

digital products for a global economy

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