On the bright side, using only id works as expected...
That brings to my next question: how can a limited number of services
implementing the same interface can be advised ?
I have now that "ServiceUpdater is matched by 4 services: AmazonServiceUpdater,
DoodleServiceUpdater, OSServiceUpdater, ServiceUpdaterCache"
And I want to advice only AmazonServiceUpdater and OSServiceUpdater.
Can I use regex on service id ?
I tried something like @Advise(id = "[OS|Amazon]ServiceUpdater") with
no luck, and cannot use @Advise(id = "*ServiceUpdater") (otherwise I go the
DoodleServiceUpdater too, which is wrong)
I can refactor the code and provide only one method like
buildTheServiceUpdater(..) and the use @Advise(id = "TheServiceUpdater"), but
that might prevent me in the future to instantiate easily the two services
separately.
-- Alessio
On Oct 3, 2013, at 5:10 PM, Alessio Gambi wrote:
>> Could you please file a JIRA?
>
> Here we go: TAP5-2195
>
>
>
>
>
> On Oct 2, 2013, at 8:37 PM, Thiago H de Paula Figueiredo wrote:
>
>> On Wed, 02 Oct 2013 11:49:54 -0300, Alessio Gambi <alessioga...@gmail.com>
>> wrote:
>>
>>> From the documentation (see
>>> http://tapestry.apache.org/service-advisors.html), it seems to be legal to
>>> combine the Advice and Match annotations:
>>>
>>> @Advise(serviceInterface=MyService.class)
>>> @Match("*DAO")
>>> public static void byMatchAnnotation(MethodAdviceReceiver receiver)
>>
>> This looks to me like a bad copy and paste from the previous example which
>> forgot to delete the @Match annotation.
>>
>>>> I'd vote for misuse. :P
>>> Than the documentation should be updated.
>>
>> Yep. And the code fixed to either make it work or to throw an exception when
>> both annotations are used in the same method.
>>
>>> public static ServiceUpdater buildOSServiceUpdater
>>> public static ServiceUpdater buildAmazonServiceUpdater
>>> public ServiceUpdaterCache buildServiceUpdaterCache
>>>
>>> Where the interface ServiceUpdaterCache extends ServiceUpdater.
>>>
>>> Therefore I should have 3 different services whose service-ids are:
>>>
>>> OSServiceUpdater
>>> AmazonServiceUpdater
>>> ServiceUpdaterCache
>>>
>>> Thus by declaring the following annotations
>>>
>>> 1) @Advise(serviceInterface = ServiceUpdater.class)
>>> 2) @Advise(id = "ServiceUpdater", serviceInterface = ServiceUpdater.class)
>>> 3) @Advise(id = "OSServiceUpdater", serviceInterface = ServiceUpdater.class)
>>>
>>> I expect the following outcomes:
>>>
>>> 1) That all three services (at least the 2 that are actually invoked at
>>> runtime) get the same advice
>>> 2) No service get the advice, as no one has matching service id
>>> 3) Only the OSServiceUpdater gets the advice.
>>>
>>>
>>> But what I actually get is:
>>>
>>> 1) Ok: both OSServiceUpdater and ServiceUpdaterCache get the advice
>>> 2) NOT OK: both OSServiceUpdater and ServiceUpdaterCache get the advice,
>>> while none should
>>> 3) NOT OK: both OSServiceUpdater and ServiceUpdaterCache get the advice,
>>> while only OSServiceUpdater should
>>
>> It seems that the code handling @Advise is ignoring id when serviceInterface
>> is set. I think Tapestry-IoC shouldn't let both attributes (id and
>> serviceInterface) to be used at the same time. It doesn't make sense.
>>
>> Could you please file a JIRA? And thank you very much for reporting and
>> investigating this issue. ;) That's a very good way of contributing to the
>> project. :)
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
