Just for those who are interested in, i used the solution suggested by
Kristian. Module code looks like :
public static void bind(ServiceBinder binder) {
binder.bind(AuthorizedQueryStringParameterManager.class,
AuthorizedQueryStringParameterManagerImpl.class);
addWhiteAndBlackLists(binder, "AuthorizedQueryString");
...
}
private static void addWhiteAndBlackLists(ServiceBinder binder, String
prefix) {
binder.bind(BlackListManager.class,
BlackListManagerImpl.class).withId(prefix + "BlackList");
binder.bind(WhiteListManager.class,
WhiteListManagerImpl.class).withId(prefix + "WhiteList");
}
Each service will have then two contributeXxx methods, one for White List
and the other for Black List.
Thanks Kristian for guidance.
PS : i'll see for a Marker solution when i have time to go deep in Module
loading stuff :)
2010/2/4 cordenier christophe <christophe.corden...@gmail.com>
>
>
> 2010/2/4 Kristian Marinkovic <kristian.marinko...@porsche.co.at>
>
>> as with the activation context i think it would be very
>>
>> error prone (from my exprience). what if you really
>> swap the parameter positions, consider more than
>> two parameters. i think the chance to create bugs that
>> cannot be detected by unit tests increases. except you
>> have very good integration tests.
>>
>> but... if we had additional positional annotations
>> or an own marker annotation to distinguish them....
>>
>> i think it would we a good idea as you could spare
>> some indirections
>>
>
> Nice idea !
>
>
>>
>> g,
>> kris
>>
>>
>>
>>
>> cordenier christophe <christophe.corden...@gmail.com>
>> 04.02.2010 15:16
>> Bitte antworten an
>> "Tapestry users" <users@tapestry.apache.org>
>>
>>
>> An
>> Tapestry users <users@tapestry.apache.org>
>> Kopie
>>
>> Thema
>> Re: Multiple configuration items per service
>>
>>
>>
>>
>>
>>
>> 2010/2/4 Kristian Marinkovic <kristian.marinko...@porsche.co.at>
>>
>> > hi,
>> >
>> > i guess it is so because it is difficult to distinguish the
>> > contributions if they are of the same type:
>> >
>> > Filter(Collection<String> whitelist, Collection<String> blacklist>)
>> >
>> > contribute(Configuration<String> blacklist, Configuration<String>
>> > whitelist)
>> >
>>
>> Also i think ordering should be sufficiant, this is what happen with
>> activation context methods. Don't you think ?
>>
>>
>> >
>> > i solve these type of problems by creating two seperate services either
>> > with an own interface (BlackListSource, WhiteListSource) or by binding
>> the
>> > same class with two different service identifiers... just another
>> > indirection :)
>> >
>> > g,
>> > kris
>> >
>> >
>> >
>> >
>> >
>> > cordenier christophe <christophe.corden...@gmail.com>
>> > 04.02.2010 14:34
>> > Bitte antworten an
>> > "Tapestry users" <users@tapestry.apache.org>
>> >
>> >
>> > An
>> > Tapestry users <users@tapestry.apache.org>
>> > Kopie
>> >
>> > Thema
>> > Multiple configuration items per service
>> >
>> >
>> >
>> >
>> >
>> >
>> > Hi,
>> >
>> > I have a use case where i want to provide to my service a white list + a
>> > black list of patterns.This list must be extensible by the service user
>> > via
>> > a contributeXxx method.
>> > The DefaultModelDef does not allow this.
>> > I guess this is a design choice, but is it reasonnable to say that the
>> > contributeXxx should have as many configuration parameters as the
>> service
>> > constructor to accept the contribution method ?
>> >
>> > Regards,
>> > Christophe
>> >
>> >
>>
>>
>
>
> --
> Regards,
> Christophe Cordenier.
>
>
> Developer of wooki @wookicentral.com
>
--
Regards,
Christophe Cordenier.
Developer of wooki @wookicentral.com
