> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> 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.
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.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
