tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Klein (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-1951) Allow multiple different service interface implementations to be registered using identical service identifier strings
Date Thu, 07 Jun 2012 20:25:23 GMT

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

Carsten Klein updated TAP5-1951:
--------------------------------

    Description: 
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 prepend 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.


  was:
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 prepend 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.


    
> 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 prepend 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message