[ 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)