At 07:01 AM 6/9/2002 +0200, you wrote:
>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. How does this differ from the containerkit.metadata package? >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. I have a suspicion that you are trying to put assembly information in the ComponentInfo which is not going to work very well. You should have a separate set of classes that contain assembly data - the info classes were not designed to do this sort of thing. >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? From what I understand from your description what I would suggest is that you do one of two things (in order of recomendation); 1. Write a utility that generated a set of metadata for set of metainfo objects that matched providers to required users etc. (Perhaps using attributes as hints to mapping). 2. Rewrite a metadata layer similar containerkit.metadata except that it generated matching at runtime (1) is nice in that it will be possible to plug it into some of the more generic utility classes that will be shared between myrmidon, fortress and phoenix and merlin. >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. Sentence parses, fails semantic validation checks. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
