Peter Donald wrote:
> At 09:33 PM 6/8/2002 +0000, you wrote:
>
>> mcconnell 2002/06/08 14:33:51
>>
>> Modified:
>> containerkit/src/java/org/apache/excalibur/containerkit/metainfo
>> AbstractServiceDescriptor.java ComponentInfo.java
>> DependencyDescriptor.java ServiceDescriptor.java
>>
>> containerkit/src/java/org/apache/excalibur/containerkit/verifier
>> AssemblyVerifier.java
>> Log:
>> addition of reverse association between dependency -> componet info
>> and service -> component info
>
>
> I am not sure that the *Descriptor should be referring to
> ComponentInfo. The main reason is that I see that in some
> circumstances it would be useful to sub-class ComponentInfo (say to
> include more metadata) but you should never be sub-classing the
> *Descriptors. And thus when you accesss ComponentInfo from a
> Descriptor you may need to cast it to get the actual Info object which
> seems icky. So can we just omit those back-pointers?
I've put in place a specilization of ComponentInfo that I'm using to
build up a model of associations between component types. Its basically
doing the construction of associations between supply components type
service declarations and dependent component type dependency
declarations. Dropping the references to the "owning" component type
means that there is no way to traverse the relationship which introduces
a lot more problems the casting to ComponentInfo derived type (which is
under my control). Without pointers to the owner I would need to pass
much a more generalized type around inside the code with big losses on
type-safety, or alternatively putting in holders that bind together the
xxxDescriptor with the ComponentInfo base - and that's not a nice scenario.
Just for reference - the key things that this is bringing up are the
decision points concerning polici8es to apply - for example, what policy
should be applied concerning the selection of a supplier service
candidate - Phoenix uses exact matching whereas Merlin allows a provider
types that are assignable to the service type. Instead of linking into
to Merlin, I'm basically playing around with options on how attributes
can be used to (a) communicate policies such as these to the container,
and (b) enable interception points for component implementations to take
an active role in decision points - e.g. given two services providing
the same role the options are open in terms of who and how the selection
process is undertaken - is it the kernel, the component implementation,
etc. If its the kernel, how can we declare "standard" policies shared by
Merlin, Phoenix and other kernel implementation? If it's the component -
what sort of attribute information would make sense at the level of a
supplier component and the corresponding dependency declarations? So far
things are looking quite promising - the level of validation without
instantiation is quite impressive which will really help in
pre-deployment tools. Something else that seems to be emerging is that
the chain configuration approach cannot easily be replaced with a
attribute model - so, I'm focussing on how attributes can declare the
policy to the container concerning (a) the establishment of static
release default configuration information, and (b) a policy through
which a component can take an active role assembly, but driven by
"assembly policy configurations". Both of these topics are circulating
in my head with the objective of enabling transparent redeployment
between Phoenix and Merlin. The direction I currently thinking is
towards plugabble policies and interceptors. Policy enabling medication
of decisions, and interceptors enabling modification of actions.
But thats all for tonight!
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]>
