Subject: Re: Merlin Roles From: Stephen McConnell <[EMAIL PROTECTED]> Reply-To: "Avalon framework users" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.jakarta.avalon.user
Riven, Rodney wrote: >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? > Yes. The <assemble key="girlfriend"> statement in the above example would be interprited by the container as a directive when dealing with a dependency declared by the component type PersonImp. If "girlfriend" what was not declared as the key of a dependency, a validation error would occur. > > >>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. > When you make a call on the service manager is it correct to assume that you are using the interface classname as the key? Yes. We either use the interface classname or the interface classname/role. > 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. > Is it safe to assume that your client would be ok with a JNDI based access mechanisms (that's the direction that I want to take the servlet example - i.e. the example should be totally independent of the Merlin APIs). JNDI would be ok. It would also be nice to have a way to expose the Service Manager as an alternate method. 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 >> >> > > > -- 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
