avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 14:56:25 GMT

Leo Sutic wrote:

>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>One of two things needs to happen:
>>(a) either the context related constraint information is removed from 
>>(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
>context information - that is, the context entries that the component
>requires should be made part of the .xinfo file and thus (b) in your
>list above.

I agree.

> 1. The contract for Context specifies that it is an exceptional event
>    if a context entry isn't present and the component is then
>    considered broken.
> 2. You have to document it *somewhere*. Somehow, you must be able to
>    take a component xinfo and see exactly what it requires to run.
>Number 2 is, in my opinion the most important one.

Without point 2 - you will never know that a component is runnable 
without doing a lauch test and waiting for the exception to occur. 
Without two the defintion of a portable component is a component that 
does impliment the Contextualizable interface.

>But I do not ever think you can make a context validatable. That is,
>even if you do include context information in the .xinfo, the container 
>will have no clue about what to do with it.
>You can constrain the context entry to the type:
>  <context-entry key="arbetskatalog" type="java.io.File"/>
>But how do you tell the container that the file is supposed to point at
>a context directory?

This is where the separation occurs between metainfo (the constraints) 
and metadata (the criteria). If we have a context constraint that says 
that the context must container an entry called "home" and that the 
value returned shall be a java.io.File and that it contains an entry 
called "name" and that the type is java.lang.String - I can declare this 
in an xinfo as follows:

<entry key="home" type="java.io.File"/>
<entry key="name" type="java.lang.String"/>

The next issue concerns the responsibility of the container to fulfil 
that constraint. To do this a directive is needed in the component 
desciption. For example the following information could be included in a 
application profile:

<component class="net.osm.test.MyComponent" name="test">
<entry key="name" value="Fred"/>
<entry key="home" class="java.io.File" value="../myHome"/>

In this simple example a single String argument is being supplied. The 
class must have a constructor that takes a single string value as a 
parameter. For example - the case of java.io.File - it has a constructor 
that can support the above. In the case of the name (where the default 
type is String), the String class also contains a constructor with a 
single String parameter. My experience with automated context value 
creation is that single string parameter constructors resolved using 
reflection solve 98% of the requirements. However, there are cases when 
you want to go further than this and provide multiple parameters to the 
class constructor. Support for this (together with every described here 
and context creation using custom context classes) is provided in the 
org.apache.excalibur.configuration.ContextFactory class. Using 
ContextFactory we are in effect describing the portability interface 
between a container and a component concerning context values. Given 
context constraints together with context directives - we can create the 
context object - but more importantly, we can use the context 
constraints to validate that context creation is possible without 
actually instantiating the context instance or context entries. This 
would require some new code basically along the lines of ContexFactory 
that instead of creating values - it simply separates reflection based 
validation from reflection based instantiation - and from that we know 
if the supplied criteria is valid.

Cheers, Steve.


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