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 16:50:28 GMT


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.  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.

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>


Mime
View raw message