avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [PROPOSAL] Context Defined
Date Sun, 08 Dec 2002 13:51:32 GMT


Leo Sutic wrote:

> All,
>
> the Context interface and its associated stage - Contextualizable - 
> has been the subject of much controversy. As a matter of fact, I'd say 
> that it is the single most controversial subject we have in Framework, 
> and I'd like to propose a way where I think the conflicting viewpoints 
> can be accomodated, although this will require some compromise.
>
>                               -oOo-
>
> First, there are two ways to view a context:
>
>  1) What I'll call the "Merlin" way, assumes that the context is an 
> unmodifiable map of constant, read-only data.
>
>  2) What I'll call the "Phoenix" way, extends the Merlin way by also 
> allowing operations in the Context, such as requestShutdown(). The 
> Context is here not just a source of deployment information, but also 
> a link through which the component may communicate with its container.
>
>
> Second, the differences has given rise to two groups with differing 
> viewpoints:
>
>  1) The goal of the Merlin group is component portability.
>
>  2) The goal of the Phoenix group is to be able to extend the Context 
> as needed - for example to turn it into a servlet context, ejb 
> context, etc.
>
> The *interests* of both groups are, I believe, to avoid having their 
> code become obsolete - a pure Phoenix approach would make the goal of 
> component portability unattainable, while a pure Merlin approach would 
> make Phoenix as it is now impossible. 


Leo:

Have to jump in here and say that in general, I'm really not concerned 
about code obselesence on the container side - I am concerned about code 
obselecense on the component side.  As things stand at the moment there 
are aspects of the Merlin containment architecture that I'm using on the 
clinet side - things like  the ability to declare an appliance factory 
(which lets me plug-in auto-CORBA-POA-activation).  Whee possible I'm 
trying to abstract these things out with crearly defined interfaces, 
factories, etc.   Once factoried out - it becomes a lot easier to 
discuss the contract, its implication on a containerment API, and its 
value to the component author.

>
>
> Thus, any solution must be able to accomodate the current usage within 
> Phoenix, while still making component portability a possibility.  
> Specifically, any code that can't capture the usage pattern in Phoenix 
> is, in my opinion, dead on arrival.
>
> I don't think it is possible to accomodate both sides 100%, but I do 
> think it is possible to have a solution where the Phoenix usage 
> pattern is allowed, while still keeping component portability for all 
> practical purposes. This means not 100% portability, but with very few 
> cases of non-portability, and a clear description of what is required 
> for 100% portability.
>
>                               -oOo-
>
> I'll focus on two things:
>
>  1) How does a component specify what context it requires?
>
>  2) How is this provided by the container?
>
>
> SPECIFICATION
> -------------
>
> A brief overview of how it is currently solved (as I understand it):
>
> Both cases:
> The component can specify any key-value mappings it will access via 
> the Context.get method. The specification includes the key, optionally 
> a name translation meaning that you can, for example, access 
> "avalon:work" through the key "work", and a class name indicating the 
> type of the value.
>
> As for the actual type of the context instance being given to the 
> component:
>
> Merlin:
> The component specifies a context class C. That class is instantiated 
> with the  constructor taking one Context parameter. This instance is 
> then given to the component. (This was as I understood it from 
> Stephen's emails, I haven't found any code doing this in the assembly 
> or meta packages, so I might be way off here.) 


The assembly package contains this code.
project: avalon-sandbox/assembly,
package: org.apache.avalon.assembly.lifecycle.ContextHandler

  try
  {
      Constructor constructor = clazz.getConstructor(
         new Class[]{Map.class, Context.class} );
      result = (Context)constructor.newInstance( new Object[]{map, null} );
  }
  catch( Throwable e )
  {
      throw new ContextException(
        "Unexpected exception while creating context form "
        + classname, e );
  }

This simply creates an instance of a context class (e.g. 
DefaultBlockContext) and instantiates it.  The remainder of the code is 
concerned with the population of the context entries.  The ideas I've 
talked about under the locator thread would enable this to be seperated 
out into one of many plug-in strategies.

>
>
> Phoenix:
> A BlockContext implementation is given directly to the component. No 
> way for the component to specify any other class.
>
>
> Note that both containers completely solve the problem so far as to 
> having a way to specify the expected key-value mappings accessible in 
> the Context.
>
> What is needed is a way to specify what methods should be avilable in 
> addition to a way to specify key-value mappings accessible via the 
> Context.get method. This is needed in order to be able to capture the 
> Phoenix BlockContext interface. With both meta-models, you can specify 
> a requirement for any key K to map to an object of any type V, and 
> using the standardized context keys, you can specify the meaning of 
> the value V. However, neither allows you to require a method called 
> requestShutdown() that requests a shutdown. While Merlin allows you to 
> specify an implementation class, that method can not be used to 
> provide a BlockContext.


Why not?

Using the existing assembly API, if I (component author) declare that I 
need to narrow an argument to BlockContext - then I need to declare this 
with something like:

   <type>
     <context type="org.apache.avalon.phoenix.BlockContext">
        <!-- add entries here -->
     </context>
   </type>

Then if I (as assembler) declare something like:

    <component name="fred" class="FredsComponent">
        <context class="MyBlockContext">
            <!-- creation directives -->
        </context>
    </component>

End result - the system has everything it needs to provide a 
BlockContext implementation.

Using the locator based strategy this would look like:

   <type>
     <context>
        <locator type="org.apache.avalon.phoenix.BlockContext"/>
     </context>
   </type>

A an assembly directive along the lines of:

   <component name="fred" class="MyComponent"/>

The difference between the current Merlin apprach and the locator 
approach is that the assembly directives are moved out because the 
container will attempt to resolve a service capable of providing locator 
services supporting BlockContext.

>
>
> What I intend to add is the following:
>
>  + A way to specify what mehods are required in the context.
>
>  + A restriction on what methods may be required while still remaining 
> 100% Avalon compatible.
>
>
> How to Specify Methods:
>
> The component will declare one class name designating an interface. 
> This can be done like this:
>
>     <context>
>         <require-interface 
> name="org.apache.avalon.phoenix.BlockContext"/>
>     </context> 

>
>
> This indicates that the context object being passed to contextualize() 
> must be cast-able to a BlockContext. This is read as: "The component 
> requires that all methods in the BlockContext interface is present in 
> the context, and that the context object given can be casted to a 
> BlockContext."


Yep.

>
>
> A Restriction on Methods:
>
> There will be a set of standard interfaces in Framework. Any component 
> may request any union of those interfaces. For example, if we have in 
> framework:
>
>     interface WorkDirectoryContext {
>         public File getWorkDirectory ();
>     }
>
>     interface ContextDirectoryContext {
>         public File getContextDirectory ();
>     }
>
> A component may have an interface:
>
>     interface MyContextInterface
>         extends ContextDirectoryContext,
>                 WorkDirectoryContext
>     {};
>
> And may specify that interface:
>
>     <context>
>         <require-interface name="org.example.MyContextInterface"/>
>     </context>
>
> And can expect to have the request fulfilled in any 100% Avalon 
> container. (Alternatively we can limit interfaces to Avalon Micro 
> Edition, SE, or EE, depending on the profiles we come up with for the 
> ├╝bercontainer.)  Note that this does in no way exclude specifying 
> key-value pair requirements. A component can specify key-value pairs, 
> an interface, both or neither.


If I declare BlockContext - I'm implicitly stating that (a) the suplied 
object is narrawable to any interface in the BlockContext interface 
graph + the supplied object has a bunch of keys defined by BlockContext. 
 The declaration of BlockContext should result in the import of keys 
based on a BlockContext meta and super-type meta.  This ensures that the 
container can import and detect key conflicts.

>
> A final restriction on the methods are that the method signatures must 
> be unique. That is, if we in framework have two interfaces:
>
>     interface WorkDirectoryContext {
>         public File getDirectory ();
>     }
>
>     interface ContextDirectoryContext {
>         public File getDirectory ();
>     }
>
> With identical signatures, a union of those interfaces
>
>     interface MyContextInterface
>         extends ContextDirectoryContext,
>                 WorkDirectoryContext
>     {};
>
> will only have one method, and furthermore it is *impossible* to 
> determine through which interface a call was made. That is:
>
>     MyContextInterface mci = ...;
>
>     // These two method calls are indistinguishale.
>     // There is no way, even with dynamic proxies,
>     // for the mci object to know whether the context
>     // directory or the work directory should be returned.
>     ((WorkDirectoryContext) mci).getDirectory ();
>     ((ContextDirectoryContext) mci).getDirectory ();
>
> We can ease that restriction by only requiring method signatures in 
> the interfaces in Framework to be unique, but this would make it 
> harder to promote a method into Framework. Obvious conclusion: these 
> context interfaces should be kept to a minimum.


This is the reason why I'm thinking about the preference for a single 
locator, or multiple service declarations.  This would work providing 
the locator service meta model supports supertypes. It would keep the 
model simpler - but I'm still thinking - so don;t take my comments as a 
position!

:-)

>
>
> What we allow in Framework:
>
> It is my view that the methods in Framework should be limited to 
> simple data-access methods, such as getWorkDirectory and 
> getContextDirectory, and that methods such as requestShutdown should 
> be left out. The reasoning behind this is as follows:
>
>  + There is major controversy regarding the exposure of services, such 
> as requestShutdown (in particular that one).
>
>  + Few components in Phoenix uses that method.
>
>  + In fact, I think most Phoenix blocks only use the 
> getContextDirectory method.
>
>  + Therefore, we can lower the requirements on those blocks, thus 
> making them portable.
>
>  + For the few blocks that *do* require a requestShutdown or similar, 
> they can declare a requirement of BlockContext.
>
>  + Those few blocks will remain non-portable, but I guess they are so 
> few that it doesn't matter.
>
> Also, it is my opinion that:
>
>  + Addition of a context interface to Framework should be via 
> consensus vote.
>
>  + Domain-specific contexts, such as EJB contexts and servlet 
> contexts, should not be allowed into Framework, as neither EJBs nor 
> Servlets are Avalon components.


I really don't see the need for any clinet side context interfaces in 
framework beyond the existing Context and maybe one standard interface 
AvalonContext (which basically provides a name and a working directory) 
- I do see the need for a standard interface for a component that can 
provide objects by key (e.g. Locator) that may or may not be exposed 
directly to the client. The locator approach seperates the issue of how 
a context constraint is supported as district from convinience 
interfaces.  It also removes the issue of context as behavioural as 
opposed to context as a map.

>
>                               -oOo-
>
>
> PROVIDING A CONTEXT
> -------------------
>
> In the previos section I established that a component may place two 
> types of requirements on a context:
>
>  1) Key-value mappings.
>
>  2) Methods in the context interface.
>
> How to provide (1) is a solved problem and there is concensus on it. 


There are solutions - I would not call it concensus - I think there is 
more to think about on the meta side - but yes, it's the easy side of 
the equation.

>
>
> As for (2), I expect the container to have some class that implements 
> Context:
>
>     class ContextImpl implements Context { ... }
>
> That class should implement *all* Framework-level interfaces:
>
>     class ContextImpl implements Context,
>         WorkDirectoryContext, ContextDirectoryContext { ... }
>
> It can also implement any other interfaces, but this is trivial:
>
>     class ContextImpl implements Context,
>         WorkDirectoryContext,
>         ContextDirectoryContext,
>         ShutdownContext { ... }
>
> OK, given the above in the container, what happens when a component 
> requests a Context interface like this:
>
>     interface MyContextInterface
>         extends ContextDirectoryContext,
>                 WorkDirectoryContext
>     {};
>
>     <context>
>         <require-interface name="org.example.MyContextInterface"/>
>     </context>
>
> Note the following: Just because ContextImpl implements 
> ContextDirectoryContext and WorkDirectoryContext, it does *not* 
> implement MyContextInterface. The following code will fail with a 
> ClassCastException:
>
>     ContextImpl impl = new ContextImpl ();
>     MyContextInterface mci = (MyContextInterface) impl; // 
> ClassCastException
>
> Thus, we need to use a proxy object implementing the required context 
> interface. The process for a container is as follows:
>
>  1. Load the class specified in the <require-interface/> element. In 
> this case it is MyContextInterface.
>  2. For each MI in the methods in the MyContextInterface interface:
>     2.1. Find a method, M, with the same signature in the container's 
> (corresponding) ContextImpl class.
>     2.2. If a method isn't found, give up and throw an Exception 
> (ComponentNotSupported)
>     2.3. Otherwise, establish a mapping MI -> M.
>  3. Create a dynamic proxy implementing MyContextInterface.
>  4. Let the InvocationHandler map every call via the mapping 
> established in step 2.
>  5. Give this proxy to the component's contextualize() method.
>
>                               -oOo-
>
> Summary:
>
> I have shown a way to declare a context requirement for components 
> that captures all current usage patterns, and shown how the 
> requirement can be satisfied by a container. The methods shown here 
> can be used to define ServletContexts, EJB contexts, etc. as well. In 
> particular, they can be used to define the Phoenix BlockContext and 
> the JAMES MailContext. Portability suffers a little, but not enough to 
> make it an issue.


I think we are on a very similar track - several things I'm thinking 
about and not enough time right now to put down words - but I'll come 
back to this a little later.

Cheers, Steve.

>
> /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

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message