You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Carsten Klein (JIRA)" <ji...@apache.org> on 2012/06/07 22:23:22 UTC
[jira] [Created] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Carsten Klein created TAP5-1951:
-----------------------------------
Summary: 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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 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.
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 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 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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 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.
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 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 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (TAP5-1951) Allow multiple different service
interface implementations to be registered using identical service
identifier strings
Posted by "Carsten Klein (JIRA)" <ji...@apache.org>.
[ 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