Rodney:


Riven, Rodney wrote:

From what I saw, this would probably impact dependency and service. A
solution could be as follows:
<service
type="blah.foo:1.0:role_hint" />
then on dependency <dependency
role="blah.foo/my_role"
type="blah.foo:1.0:role_hint" />



A couple of problems here - structurally speaking we should not be holding any information in the type descriptor concerning assembly information, and secondly, this introduces semantics into the type key that can/should be handled at the level of attributes.




This would allow a service to be dependent on a particular implementation of
a given service without a lot of impact to the entire meta-data structure.


What I have been thinking about is something like the following:


Assembly of a component dependency using a named component.

<component name="sally" class="PersonImp"/>

 <component name="fred" class="PersonImp">
   <assembly>
     <assemble key="girlfriend" use="sally"/>
   </assembly>
 </component>

Assembly of a component dependency using a selection constraint:

<component name="sally" class="PersonImp"/>

 <component name="fred" class="PersonImp">
   <assembly>
     <assemble key="girlfriend">
       <select feature="hair" constraint="red"/>
       <select feature="age" value="gt(21)"/>
     </assemble>
   </assembly>
 </component>

In the second case a constraint could be a regular expression of some sort. In the above example a feature would simply correspond to an attribute in a candidate <service> definition, or an attribute in the <info> block of the source component (in that order - i.e. attributes in the service definition override attributes in the info definition). This information would then be used to parameterize a profile/appliance selector internally within Merlin.



Additionally, I also have a question about embedding Merlin in a servlet.
Is there a way to embed it that does not require url's for service
resolution?



A very guarded yes.


We have some non-avalon objects that use the services and i was wondering if there was an easier way to get them to talk


This is something I have been playing with as part of remote service management - for example - using block urls to map to corbaloc urls which establish non-Avalon components. I'm currently using a custom appliance to do this but I don't want to encorage this as it locks you into the API more deaply than needed.


What is the object/component model that we are talking about here? Specifically, how are you establishing the component and its services?

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to