Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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
>>
>>
>
>Stephen,
>
>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.
>Reasons:
>
> 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:
<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. 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
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
