Berin Loritsch wrote:
Farr, Aaron wrote:
-----Original Message----- From: Berin Loritsch [mailto:[EMAIL PROTECTED]
[] for an array of components implementing the service {} for a map of components implementing the service /name for a specific instance implementing a service
Currently there is no standard way of doing this. And (brace yourself for
the
"d" word) Phoenix is divergent from the common definition of acceptable
return
types from the ServiceManager due to the List and Map return values.
I kind of like the [], {}, and / methods, but I'm not completely sold yet.
So if I understand it, the current methods of look up are:
Object <- lookup("alias") Object* <- lookup(ROLE) Object <- lookup(ROLE+"/alias") Object[] <- lookup(ROLE+"[]")
List <- lookup(ROLE+"[]")
Map <- lookup(ROLE+"{}") Selector <- lookup(ROLE+"Selector")
* - in this case, you can either get the Object you are looking for, or a
ServiceSelector. To be really safe, you have to test for both.
-1. In Fortress, any lookup to a simple ROLE returns the default component
for that role, no matter how many implementations/configurations there
are. The only way to get a ServiceSelector is to use the ROLE+"Selector".
It simplifies client code when they know what they are getting every time.
As to the list above, here is a matrix of where they work:
Lookup Method | ECM | Fortress | Merlin | Phoenix
--------------------------------------+-----+----------+--------+--------
Object <- lookup("alias") | | | X | X
Object <- lookup(ROLE) | X | X | X | X
Object <- lookup(ROLE+"/alias") | | X | X | X
Relative to service manager and component manager semantics, Merlin provides support for the following:
Object <- lookup( "key" ) // where key if declared in meta-info Object <- lookup( ROLE ) // whee role is the interface name
Anything else is in the wobbly zone.
Phoenix ignores the ServiceSelector contract--even though it is in Framework.
I believe Merlin supports the ServiceSelector, but I am not sure so I will
leave it to Stephen to tell us more authoritatively.
Nope - Merlin does not implement this simply because the specification is way insufficient to provide a predictable result. If you want a selector then declare a dependency on a service that implements some selection strategy.
As to the lookup values themselves, both Merlin and Phoenix treat the lookup
value strictly like the first option (i.e. "alias"), no matter what is looked
up. The key difference is in how dependencies are declared in the JavaDoc
tags. Phoenix allows for certain suffixes to determine the output. Fortress
also does this indirectly (it doesn't recognize suffixes to the type value,
but it interprets the lookup value).
In the end, I would like a way that works easily without having to think too
hard. I have come to appreciate the simplicity of simple name/value mapping,
as long as there is a way to influence that mapping.
The way to influence the mapping is what meta-data is all about.
* One or more "role" attribtues identified with names--supply the
implementations of the type that the assembler identifies as that role.
Not quite following. Do you mean something like:
@dependency type="org.proj.MyService" role="role1" role="role2"
MyService service = (MyService) serviceManager.lookup("role1");
MyService another = (MyService) serviceManager.lookup("role2");
[spit snarl growl] If you want the above then:
@dependency key="role1" type="org.proj.MyService" @dependency key="role2" type="org.proj.MyService"
Yes.
[spit spit snarl snarl growl growl]
If the tool won't allow us to have more than one attribute with the same
name, then we can make it a list of roles using a comma (",") to seprate them.
This is for those instances when we know beyond the shadow of a doubt how a
particular component will be used.
If it's a different role then its a different deployment scenario. As such is a distincly different dependency. I dependency is not about just the interface classname - its about a deployed solution, taking into account configuration, services, porerties, context, etc., etc. Each dependency can be translated to a distinct and identifiable scenario. The interface that happens to be common is just a small part of the equation. You could come up with a default value for type (e.g. java.lang.String) but you cannot come up with a default key.
* One "role" attribute with the value "*"--all implementations of the type
need to be available to the component.
Something like this is probably needed. Maybe this sounds like overkill,
but what about allowing some sort of regular expression?
I think regular expressions would be overkill in this case. Either we know
ahead of time what components we want to use or we don't. If we get too fancy,
we will run into issues like "I defined my regular expression like this ... and
my component is named ..., so how come the container can't match it up?" Its
just another point of failure we can do without.
Regualar expressions could be used providing they deal with things like attributes. This is something that amakes a lot of sence with respect to selection strategies - but keep in mind that I'm talking about container side selection here (and the elimination of the need to use selection in component land).
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]
