avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: shutdown phoenix gracefully
Date Sat, 31 Aug 2002 13:08:50 GMT

Hi Paul:

Paul Hammant wrote:
> Stephen,
> 
>>> requestShutdown();
>>
>>
>> As noted in the thread over phoenix-dev, the addition of the operation 
>> requestShutdown to BlockContext (as currently proposed) breaks the 
>> component contract related to Contextualizable.  A component receives 
>> a Context object which is holder a keyed values.  Adding behaviour 
>> breaks potential for component portability. 
> 
> 
> BlockContext extending Context is a 'mistake' we have made and not 
> noticed for mutiple years.  Given that the current advice for PhoenixAPI 
> compatible containers is to include the phoenix-client.jar in their CVS 
> and distribution, there is only a small amount of additional work to 
> code  implemetation of requestShutdown().
> 
>> There are alternative solutions such a component requesting a 
>> depedency on a shutdown request handler which would be totally 
>> consistent eith the component model.  Another less portable solution 
>> would be expose a shutdown request handler object via a context key - 
>> the component that requires this functionality would get the handler 
>> and invoke a shutdown request against the handler.
> 
> 
> It could be that there is such a key to another interface called say 
> ShutdownHandler (in the same package as BlockContext?), 

This is an improvement in that it seperates the behaviour out of the 
context object.  An even better solution would be for component to 
declare a service dependency on a shutdown handler.

> this ain't much 
> different to requestShutdown() in BlockContext though.

There isn't much difference from the point of view of a programmer. 
There is a lot of difference from the point of view of consitency with 
respect to the Avalon Component Model.  Within the model we have 
declared a series of objects types that communication information 
between a container and a component.  There include the Logger, Context, 
  Parameters, Configuration and ServiceManger/ComponentManager, etc. 
Each of these resources provide defined semantics (some better than 
others). In the case of the Context type, the semantics are about access 
to a keyed value.  If the key does not exist, a ContextException if 
thrown.  There is perhaps a missing declaration of an incompatible type.

> This I guess is tied up in the late but long argument on whether there 
> should be a BlockContext at all for enterprise level Avalon containers.

Exactly - the very existence of BlockContext defined a specilization of 
the Avalon component model for Phoenix.  Phoenix blocks assume that 
casting to BlockContext is part of the contract.  Within the scope of an 
application/block written and dedicated to execution in the Phoenix 
environment - this is a reasonable assumption.  If a component is 
written in accordance with the Avalon component model it will deal with 
the supplied context object in accordance with the Avalon component 
model specification - i.e. strict key lookup and no narrowing of a 
context argument to something outside of the framework set of interaces.

The introduction of a more complete meta-info model at the framework 
level would change this.  The benefits of including a meta-info model 
are that we introduce more explicit defintion of these resources that 
are supplied between the container and the component it is managing. 
For example, in the case of a Context depedendency, the ability for a 
component to declare the keys and the type of object associated with the 
key.

In the absence of a framework meta-info model the fallback position is 
the Avalon framework component model + container specific adornments. 
For example, Phoenix supplies the blockinfo definition in order to 
establish available services and dependecies, Merlin provides similar 
functionality that also addresses component context and other criteria.

Where we are today:

   1. The base line is the Avalon Framework Component Model.

An interim solution is:

   2. Defintion of a set of Avalon level common context keys
      and the associated specification of the object type and
      related semantics.

      But keep in mind that this is verging on the modification
      of the Avalon component model - what it implies is that
      the we are modifying the semantics associated with the
      contextualization phase of an Avalon component - should
      every invocation of contextualize include common keys and
      values?

      The answer to that is no!

      What the interim solution does provide is a mechanism
      enabling better management of interoperability between
      containers in the absense of a common meta-info model.

And the longer term solution is:

   3. Defintion of a Avalon meta-info model that enables a
      component to more completely declare its depedencies
      and capabilities

Cheers, Steve.


> Regards,
> 
> - Paul
> 
> 
> 
> -- 
> 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