-----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
List <- lookup(ROLE+"[]") | | | | X
Map <- lookup(ROLE+"{}") | | | | X
Selector <- lookup(ROLE+"Selector") | X | X | ? |As you can see, there are only a couple of ways that would be widely used. 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.
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.
* 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");
Yes. 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.
* 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.
Probably step in the right direction; however, I think I (and other users) will get 'role' and 'type' mixed up.
Hmm. That is a problem. Perhaps we simply need to add these semantics to the "alias" attribute?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
