You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Peter Rietzler (JIRA)" <ji...@apache.org> on 2009/12/16 08:26:18 UTC
[jira] Created: (TAP5-956) Refactor Save Service Contributions
Refactor Save Service Contributions
-----------------------------------
Key: TAP5-956
URL: https://issues.apache.org/jira/browse/TAP5-956
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-ioc
Reporter: Peter Rietzler
Service contributions are determined through the service name and the 'contribute<ServiceName>' method. Prior to 5.1 this lead to problems when service interface names were refactored (and with https://issues.apache.org/jira/browse/TAP5-955 this problem arises again because optional contributions would be ignored ...).
Prior to 5.1, when service contributions were ignored if they did not match, we 'worked around' (actually no workaround is required but we wanted to be a bit more refactoring safe ...) this issue using the following pattern:
{code}
class ModuleContributions {
public static final String MY_SERVICE = "myService";
}
class Module {
public static void bind(ServiceBinder binder) {
binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
}
}
class AnotherModule {
public static void contributeMyService(....) { ... }
}
{code}
As long as we do not change the MY_SERVICE constants everything works fine.
It would be easy to support fully refactoring safe contributions, e.g.:
{code}
binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
@Contribute(to = ModuleContributions.MY_SERVICE)
public static void arbitraryContributionMethodName(...)
{code}
or
{code}
binder.bind(MyService.class, MyServiceImpl.class);
@Contribute(to = MyService.class)
public static void arbitraryContributionMethodName(...)
{code}
or (with markers)
{code}
binder.bind(MyService.class, MyServiceImpl.class);
@Contribute(to = MyService.class)
@MyServiceMarker
public static void arbitraryContributionMethodName(...)
{code}
This would additionally support https://issues.apache.org/jira/browse/TAP5-955 becuase the @Contribute annotation could have another parameter, e.g. optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-956) Refactor Save Service Contributions
Posted by "Igor Drobiazko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Drobiazko reassigned TAP5-956:
-----------------------------------
Assignee: Igor Drobiazko
> Refactor Save Service Contributions
> -----------------------------------
>
> Key: TAP5-956
> URL: https://issues.apache.org/jira/browse/TAP5-956
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Reporter: Peter Rietzler
> Assignee: Igor Drobiazko
>
> Service contributions are determined through the service name and the 'contribute<ServiceName>' method. Prior to 5.1 this lead to problems when service interface names were refactored (and with https://issues.apache.org/jira/browse/TAP5-955 this problem arises again because optional contributions would be ignored ...).
> Prior to 5.1, when service contributions were ignored if they did not match, we 'worked around' (actually no workaround is required but we wanted to be a bit more refactoring safe ...) this issue using the following pattern:
> {code}
> class ModuleContributions {
> public static final String MY_SERVICE = "myService";
> }
> class Module {
> public static void bind(ServiceBinder binder) {
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> }
> }
> class AnotherModule {
> public static void contributeMyService(....) { ... }
> }
> {code}
> As long as we do not change the MY_SERVICE constants everything works fine.
> It would be easy to support fully refactoring safe contributions, e.g.:
> {code}
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> @Contribute(to = ModuleContributions.MY_SERVICE)
> public static void arbitraryContributionMethodName(...)
> {code}
> or
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> public static void arbitraryContributionMethodName(...)
> {code}
> or (with markers)
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> @MyServiceMarker
> public static void arbitraryContributionMethodName(...)
> {code}
> This would additionally support https://issues.apache.org/jira/browse/TAP5-955 becuase the @Contribute annotation could have another parameter, e.g. optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-956) Refactor Save Service Contributions
Posted by "Igor Drobiazko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Drobiazko closed TAP5-956.
-------------------------------
Resolution: Duplicate
Duplicate of TAP5-69
> Refactor Save Service Contributions
> -----------------------------------
>
> Key: TAP5-956
> URL: https://issues.apache.org/jira/browse/TAP5-956
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Reporter: Peter Rietzler
> Assignee: Igor Drobiazko
>
> Service contributions are determined through the service name and the 'contribute<ServiceName>' method. Prior to 5.1 this lead to problems when service interface names were refactored (and with https://issues.apache.org/jira/browse/TAP5-955 this problem arises again because optional contributions would be ignored ...).
> Prior to 5.1, when service contributions were ignored if they did not match, we 'worked around' (actually no workaround is required but we wanted to be a bit more refactoring safe ...) this issue using the following pattern:
> {code}
> class ModuleContributions {
> public static final String MY_SERVICE = "myService";
> }
> class Module {
> public static void bind(ServiceBinder binder) {
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> }
> }
> class AnotherModule {
> public static void contributeMyService(....) { ... }
> }
> {code}
> As long as we do not change the MY_SERVICE constants everything works fine.
> It would be easy to support fully refactoring safe contributions, e.g.:
> {code}
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> @Contribute(to = ModuleContributions.MY_SERVICE)
> public static void arbitraryContributionMethodName(...)
> {code}
> or
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> public static void arbitraryContributionMethodName(...)
> {code}
> or (with markers)
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> @MyServiceMarker
> public static void arbitraryContributionMethodName(...)
> {code}
> This would additionally support https://issues.apache.org/jira/browse/TAP5-955 becuase the @Contribute annotation could have another parameter, e.g. optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-956) Refactor Save Service Contributions
Posted by "Igor Drobiazko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Drobiazko reassigned TAP5-956:
-----------------------------------
Assignee: Igor Drobiazko
> Refactor Save Service Contributions
> -----------------------------------
>
> Key: TAP5-956
> URL: https://issues.apache.org/jira/browse/TAP5-956
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Reporter: Peter Rietzler
> Assignee: Igor Drobiazko
>
> Service contributions are determined through the service name and the 'contribute<ServiceName>' method. Prior to 5.1 this lead to problems when service interface names were refactored (and with https://issues.apache.org/jira/browse/TAP5-955 this problem arises again because optional contributions would be ignored ...).
> Prior to 5.1, when service contributions were ignored if they did not match, we 'worked around' (actually no workaround is required but we wanted to be a bit more refactoring safe ...) this issue using the following pattern:
> {code}
> class ModuleContributions {
> public static final String MY_SERVICE = "myService";
> }
> class Module {
> public static void bind(ServiceBinder binder) {
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> }
> }
> class AnotherModule {
> public static void contributeMyService(....) { ... }
> }
> {code}
> As long as we do not change the MY_SERVICE constants everything works fine.
> It would be easy to support fully refactoring safe contributions, e.g.:
> {code}
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> @Contribute(to = ModuleContributions.MY_SERVICE)
> public static void arbitraryContributionMethodName(...)
> {code}
> or
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> public static void arbitraryContributionMethodName(...)
> {code}
> or (with markers)
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> @MyServiceMarker
> public static void arbitraryContributionMethodName(...)
> {code}
> This would additionally support https://issues.apache.org/jira/browse/TAP5-955 becuase the @Contribute annotation could have another parameter, e.g. optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-956) Refactor Save Service Contributions
Posted by "Igor Drobiazko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Drobiazko closed TAP5-956.
-------------------------------
Resolution: Duplicate
Duplicate of TAP5-69
> Refactor Save Service Contributions
> -----------------------------------
>
> Key: TAP5-956
> URL: https://issues.apache.org/jira/browse/TAP5-956
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-ioc
> Reporter: Peter Rietzler
> Assignee: Igor Drobiazko
>
> Service contributions are determined through the service name and the 'contribute<ServiceName>' method. Prior to 5.1 this lead to problems when service interface names were refactored (and with https://issues.apache.org/jira/browse/TAP5-955 this problem arises again because optional contributions would be ignored ...).
> Prior to 5.1, when service contributions were ignored if they did not match, we 'worked around' (actually no workaround is required but we wanted to be a bit more refactoring safe ...) this issue using the following pattern:
> {code}
> class ModuleContributions {
> public static final String MY_SERVICE = "myService";
> }
> class Module {
> public static void bind(ServiceBinder binder) {
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> }
> }
> class AnotherModule {
> public static void contributeMyService(....) { ... }
> }
> {code}
> As long as we do not change the MY_SERVICE constants everything works fine.
> It would be easy to support fully refactoring safe contributions, e.g.:
> {code}
> binder.bind(MyService.class, MyServiceImpl.class).withId(ModuleContributions.MY_SERVICE);
> @Contribute(to = ModuleContributions.MY_SERVICE)
> public static void arbitraryContributionMethodName(...)
> {code}
> or
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> public static void arbitraryContributionMethodName(...)
> {code}
> or (with markers)
> {code}
> binder.bind(MyService.class, MyServiceImpl.class);
> @Contribute(to = MyService.class)
> @MyServiceMarker
> public static void arbitraryContributionMethodName(...)
> {code}
> This would additionally support https://issues.apache.org/jira/browse/TAP5-955 becuase the @Contribute annotation could have another parameter, e.g. optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.