[jira] [Resolved] (TAP5-1951) Allow multiple different service interface implementations to be registered using identical service identifier strings

["Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thiago H. de Paula Figueiredo resolved TAP5-1951.
-------------------------------------------------

    Resolution: Won't Fix

The feature suggested here can be better implemented with marker annotations instead of using service id for selecting one implementation from many of the same service interface.

> Allow multiple different service interface implementations to be registered using identical service identifier strings
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1951
>                 URL: https://issues.apache.org/jira/browse/TAP5-1951
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-ioc
>    Affects Versions: 5.3.3
>            Reporter: Carsten Klein
>            Priority: Minor
>
> As of now, tapestry-ioc maintains a global namespace for all of the registered service ids.
> This makes it impossible to bind different service interfaces and their implementations 
> thereof using the same service identifiers, e.g.
> binder.bind(IFirstService.class, FirstServiceDefaultImpl.class).withId("default");
> binder.bind(ISecondService.class, SecondServiceDefaultImpl.class).withId("default);
> This will result in an exception on container and application startup.
> I think that, having played around with Plexus for a while, it would be nice to allow duplicate 
> service ids for different service interfaces, as it makes documentation and using one's APIs 
> a lot easier, when one can refer to "default" instead of for example "secondservice.default" 
> and so on.
> As for the performance impact, one could always use the fully qualified name of the service 
> interface class and append to it the service identifier. This is very similar to the user 
> disambiguating the service identifiers by herself, except that tapestry-ioc would use the 
> namespaces provided by the application instead, e.g.
> when doing 
> binder.bind(...).withId("default);
> the service binder would then
> this.registry.registerServiceById(serviceInterfaceClass.getName() + "." + serviceId, serviceInterfaceClass, implClass); 
> or something like that.



--
This message was sent by Atlassian JIRA
(v6.1#6144)