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 17:43:19 GMT

Stephen McConnell wrote:
> Nicola Ken Barozzi wrote:
>> Leo Sutic wrote:
>>>> From: Stephen McConnell [mailto:mcconnell@osm.net] 
>> ...
>>>> 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:
>>>> <component-info>
>>>> <context>
>>>> <entry key="home" type="java.io.File"/>
>>>> <entry key="name" type="java.lang.String"/>
>>>> </context>
>>>> </component-info>
>>>> 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 
>>>> 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.
>>> 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)
> I'll ignore the fact that the above interface is unfortunately named 
> Context and consider this just an interface to a java Object which is 
> exposed in an avalon Context instance. 

;-) Yeah.

> The more import criteria 
> relative to this thread is how an instance can be created. I would like 
> to dig a little into this example and demonstrate how a component can 
> declare, validate and instantiate a context containing an object 
> implementing the above interface.
> First of all - we have the declaration by the componet type that it 
> needs to be supplied with a (Avalon) Context instance that contains an 
> object that implements the (Cocoon) Context interface.
>    <component-info>
>       <context>
>           <entry key="cocoon-context" type="somewhere.cocoon.Context"/>
>       </context>
>    </component-info>
> The next issue concerns the declaration of the criteria for the creation 
> of the context object (assuming that we are building a portable 
> component).  The following enty is an example based on the existing 
> ContextFactory appraoch.
>    <component name="cocoon-thing" 
> class="somewhere.cocoon.CocoonRelatedComponent".>
>        <context>
>            <entry name="cocoon-context 
> class="somewhere.cocoon.DefaultCocoonContext">
>                <param name="url" 
> value="http://somewhere.something/value.whatever"/>
>                <param name="mime" value="a-mime-value"/>
>                <param name="mime" value="a-mime-value"/>
>                <param name="init-params" 
> value="initial-params.properties" class="java.io.File"/>
>                <param name="attributes" value="attributes.properties" 
> class="java.io.File"/>
>            </entry>
>        </context>
>    </component>
>   Given the above example - ContextFactory (one example of declarative 
> context management) creates a new instance of DefaultCocoonContext using 
> the 5 parameters as constructor arguments.  The resulting object is then 
> added to the context map under the key "cocoon-thing".  Using the above, 
> the cocoon component that need a context object as descibed, can now be 
> portable - i.e. it can be deployed independently of the container - it 
> can still be managed inside a system programatically but it also has the 
> full declaration of how it can be managed outside of a cocoon specific 
> environment and independent of a specific container.

Ok, I like this :-)

Just one more question: how about the stuff that Cocoon Components use 
to get info about the request, the response, etc...

How do you think Cocoon should supply them?

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