In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> 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.
>
In this case would the key used to assemble the component match the key/role
of the dependency?
>
>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.
What we have is an enhanced struts based web-app. We wrappered struts to
have it run on a services based framework. So the regular code will be the
struts actions, etc. Then when they need
services provided (ie. caching, lookups, etc.) they currently call a service
manager and lookup the service. We are moving to avalon in order to have a
better lifecycle and are looking at merlin to
provide the proper dependencies between the many services that are currently
in our application. The issue for us is that the customer will not allow the
url method of your current servlet example. So,
I was wondering if there was another way to embed merlin that would work a
little more like our current way.
>
>--
>
>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
