Is it possible that @Contribute works with @Marker to make
contribution to a specified service in multiple implementation of one
interface?
e.g.
@Marker(Service1Marker.class)
Service buildService1() {};
@Marker(Service2Marker.class)
Service buildService2() {};
@Contribute(Service.class)
@Marker(Service1Marker.class)
public static void foo1(MappedConfiguration<String,String> configuration)
@Contribute(Service.class)
@Marker(Service2Marker.class)
public static void foo2(MappedConfiguration<String,String> configuration)
Now I have to use
contributeService1(MappedConfiguration <String,String> configuration);
contributeService2(MappedConfiguration <String,String> configuration);
Which is not refactoring safe.
Thanks,
Yunhua
On Tue, Jan 13, 2009 at 4:38 PM, Fernando Padilla <[email protected]> wrote:
> right, so the current extra precise method is still available right?
>
> but if you right a module that doesn't do precise contributions, then anyone
> importing that module will never be able to create a different service with
> the same type.. right?
>
> anyhow.. nice idea to clean up stuff, just realize that there is cost to
> having the code be too smart.. :)
>
> Igor Drobiazko wrote:
>>
>> Providing a type of the service makes you to avoid DRY. You don't have to
>> repeat the service id again.
>> So, in case of several implementations of a service interface you should
>> use
>> the naming convention and provide extra contribute method for each
>> implementation.
>>
>>
>> On Tue, Jan 13, 2009 at 10:04 PM, Fernando Padilla
>> <[email protected]>wrote:
>>
>>> So the Contribute would support either a class or an arbitrary service
>>> name? (for when there are two services who implement the same interface,
>>> etc)
>>>
>>>
>>> Igor Drobiazko wrote:
>>>
>>>> The value attribute of the annotation is used to determine the service
>>>> to
>>>> contribute into. The type of the configuration does not provide enough
>>>> information for it. See an example below:
>>>>
>>>> @Contribute(Runnable.class)
>>>> public static void bar(MappedConfiguration<String,String>
>>>> configuration)
>>>> {
>>>>
>>>> }
>>>>
>>>> @Contribute(SomeAnotherService.class)
>>>> public static void foo(MappedConfiguration<String,String>
>>>> configuration)
>>>> {
>>>>
>>>> }
>>>>
>>>> On Tue, Jan 13, 2009 at 9:53 PM, Fernando Padilla <[email protected]>
>>>> wrote:
>>>>
>>>> but what if I want to have two different services that are configured
>>>>>
>>>>> using
>>>>> the same typed configuration??
>>>>>
>>>>> the name and the type of the configuration are both important.
>>>>>
>>>>>
>>>>> Igor Drobiazko (JIRA) wrote:
>>>>>
>>>>> [
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/TAP5-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>>>> ]
>>>>>>
>>>>>> Igor Drobiazko reassigned TAP5-69:
>>>>>> ----------------------------------
>>>>>>
>>>>>> Assignee: Igor Drobiazko
>>>>>>
>>>>>> Allow service configurators to be arbitrary named and determine
>>>>>> sevice
>>>>>> by
>>>>>>
>>>>>>> the configuration parameter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: TAP5-69
>>>>>>> URL: https://issues.apache.org/jira/browse/TAP5-69
>>>>>>> Project: Tapestry 5
>>>>>>> Issue Type: Improvement
>>>>>>> Affects Versions: 5.0.15
>>>>>>> Reporter: Kalin Krustev
>>>>>>> Assignee: Igor Drobiazko
>>>>>>>
>>>>>>> Tapestry used to require this naming convention for configuring
>>>>>>> services:
>>>>>>> public static Foo buildFoo(...) {...}
>>>>>>> public static void contrubuteFoo(...) {...}
>>>>>>> Then it allowed the first convention to be simplified as:
>>>>>>> public static Foo build(...) {...}
>>>>>>> It would be nice for the "contribute..." methods to allow also
>>>>>>> simpler
>>>>>>> naming and use the type of the "configuration" parameter to determine
>>>>>>> the
>>>>>>> configured service, which will also have the same type of parameter.
>>>>>>> For example:
>>>>>>> in Tapestry 5.0.5 TapestryModule.java:
>>>>>>> public ServletApplicationInitializer build(...,
>>>>>>> List<ServletApplicationInitializerFilter> configuration, ... )
>>>>>>> in my AppModule.java Tapestry 5.0.5 requires this naming:
>>>>>>> public void
>>>>>>>
>>>>>>>
>>>>>>> contributeServletApplicationInitializer(OrderedConfiguration<ServletApplicationInitializerFilter>
>>>>>>> configuration)
>>>>>>> Perhaps it could be simplified as:
>>>>>>> public void
>>>>>>> contribute(OrderedConfiguration<ServletApplicationInitializerFilter>
>>>>>>> configuration)
>>>>>>> If it will not be simplified, it would be nice to make the
>>>>>>> documentation
>>>>>>> about Tapestry IoC Configurations more clear that
>>>>>>> the naming of the contribute methods is important, not the type of
>>>>>>> configuration parameter.
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
