avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 15:56:58 GMT

Leo Sutic wrote:
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>This is where the separation occurs between metainfo (the 
>>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"> 
>><context> <entry key="name" value="Fred"/> <entry key="home" 
>>class="java.io.File" value="../myHome"/> </context> </component>
>>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 
>>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.
> This would indicate that all values in the component
> context are supplied by the assembler (the person creating the
> component config).
> My question was regarding container-supplied context values.
> It would appear that context values entered as you describe
> are limited to:
>  + constants
>  + entered by a human
> Is this correct?
> I would then propose that we define a fixed set of context keys
> that the *container* must supply (and some that it may supply).
> For example, the context directory may be given by a servlet 
> container and should only be passed on to the components by 
> the containers.

To be concrete, this is the Cocoon Context:

public interface Context {

     Object getAttribute(String name);
     void setAttribute(String name, Object value);
     void removeAttribute(String name);
     Enumeration getAttributeNames();
     URL getResource(String path) throws MalformedURLException;
     String getRealPath(String path);
     String getMimeType(String file);
     String getInitParameter(String name);
     InputStream getResourceAsStream(String path);

As you see:
1. it doesn't extend avalon Context
2. it's gotten from the avalon context as an object via a key (ie one 
key to get the context, one to get the actual parameter)

In this, we find *services* that are of the Cocoon container:

     URL getResource(String path) throws MalformedURLException;
     String getRealPath(String path);
     String getMimeType(String file);
     InputStream getResourceAsStream(String path);

So a Context now generally contains:
- Avalon container live values
- Avalon container services
- Cocoon container live values
- Cocoon container services


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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