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.

Reply via email to