Hello again. Picking up again on last week's "service naming convention" thread [1], I still have a couple questions:
I understand that using the ServiceSelector can cause issues when a component isn't expecting a selector to be returned. Therefore, we have the following method: MyService service = (MyService) m_manager.lookup(MyService.ROLE+"/id"); which lets us lookup a specific implementation. Personally I rather like the idea of using MyService.ROLE since it has a feeling of permanence, ie- the service name is part of the "API" and not just some random string. However, I can see that this method doesn't handle some more complex situations which in fact turn up regularly. So properly devised service naming (and the use of meta-info tags) can bring regularity and structure and still handle multiple service implementations. Given this: 1. Which containers support ServiceSelector's? (ECM and Fortress, right?) 2. For the above containers, one can guarantee the actual lookup of a service object (as opposed to a selector) only if all service names are unique, correct? 3. When using String names for services, are there any particular advantages to: - [class-name]/[descriptive-name] "org.proj.MyService/store" - [descriptive-name] "store" - url / url "urn:services:store" Reason for asking is that I want to introduce best practices early to new Avalon develops (in my own developer team and via my Avalon tutorial) and also to write container-agnostic components as much as possible. The ServiceManager behavior is a rather important and basic concept in Avalon and it'd be nice to know what "always" works regardless of container environment. Thanks! J. Aaron Farr � SONY ELECTRONICS � DDP-CIM � (724) 696-7653 � [1] http://marc.theaimsgroup.com/?l=avalon-users&m=105431696332706&w=2 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
