avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject ComponentInfo navigation
Date Sun, 09 Jun 2002 05:01:03 GMT


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