Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3D249005.6060303@apache.org>
Date: Thu, 04 Jul 2002 20:12:21 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: [VOTE] ComponentMetaData change
References: <3D212869.7020407@osm.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I would to propose the addition of the following method to the 
ComponentMetaData class enabling the introduction of a Context value.

  package org.apache.excalibur.containerkit.metadata;

  import org.apache.avalon.framework.context.Context;
  impost ...

  public class ComponentMetaData
  {
      //...

      public Context getContext( Context parent )
      {
          return parent;
      }
  }

The purpose of the change is to ensure that (a) specializations of 
ComponentMetaData can introduce their own mechanisms supporting the 
creation and population of component data without forcing clients to 
narrow to a particular class specilization in order to get the value, 
and (b) ensure that Context is properly dealt with within the scope of 
containerkit and that containerkit itself can be updated to use this 
operation when aquiring the context value (as in the case with 
Parameters and Configuration values).

Here is my +1

Steve.

Stephen McConnell wrote:

>
> This message is to raise an important issue concerning containerkit.
>
> The current containkit package defines the metamodel for a component. 
> According to the metamodel a component type are defined in terms of a 
> ComponentDescriptor, a ContextDescriptor, a set of 0..n 
> ServiceDescriptor entries, a set of DependencyDescriptor entries, and 
> finally, a set of LoggerDescriptor entries. These declarations are the 
> definitive description of a component towards a container. In 
> principal, any constrains declared here should be fully supportable by 
> any container. The mechanism supporting the instantiation of a 
> component defined by a ComponentInfo can be container specific. 
> However, containterkit declares a series of metadata type - these 
> types define information that is typically included in a container 
> application profile. It includes information about the configuration 
> to be used for a particular profile of a type or the parameters to be 
> applied to that type. Unfortunately, the metadata model (i.e. the 
> object model supporting the application level component instantiation 
> criteria) does not include the *context* that is required by a 
> particular component type profile. As some of you will have seen 
> already ... Pete and I have different view on this. The objective of 
> this email is to resolve that issue.
>
> One of two things needs to happen:
>
> (a) either the context related constraint information is removed from 
> ComponetInfo
>
> (i.e. we treat context the same way we treat configuration and
> parameters - we guarantee an instance of Context and nothing more - and
> document the implication of moving outside of this constract)
>
> or, (b) context information is included in ComponentMetaData
>
> (i.e. and we leverage existing Excalibur utilities that provide support
> for this)
>
> Without a decision here we will never achieve a component validation 
> framework relative to containerkit. Components built using Phoenix 
> will not work inside other containers unless every container includes 
> specific context handling code. Contents built relative to Merlin will 
> work in Phoenix but only because Merlin will include the extensions 
> need to handle this constraint. Isn't containerkit the generalization 
> of the container abstraction? This is a serious issue - either we 
> address the constraints we are declaring, or, we make the hard and 
> fast rule that any components leveraging any typed context or is 
> assuming the availability of a context key must not be used if you 
> want a component to be reusable without resorting to a particular 
> container. That constaint is simply way too extreme. Irrespectivbe of 
> a decision to support context entries in containerkit or not, Merlin 
> will deliver this support basuase it is a fundimental to support of 
> the Avalon framework contract. I would prefer that we are up-front on 
> this. If we declare a framework related constraint in a container 
> platform - we have to deliver the tools to deliver management of that 
> constraint. If not - drop the constraint and let specific container 
> implementations get on with the job of doing real portable component 
> management - and drop the suggestion that containerkit is the common 
> platfrom.
>
> Cheers, Steve.
>
>
> 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>
>

-- 

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>