tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiago H. de Paula Figueiredo (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (TAP5-1951) Allow multiple different service interface implementations to be registered using identical service identifier strings
Date Tue, 08 Oct 2013 01:38:43 GMT

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

Mime
View raw message