> And I want to advice only AmazonServiceUpdater and OSServiceUpdater. I solved this by defining a Marker annotation @CloudServiceUpdater, place it on the two services, and finally, use the combination
@Advise @CloudServiceUpdater which seems to work just fine. I prefer this solution instead of using service id (and regex) because it is refactoring safe. Still a question remains: If @Match and @Advise should not used together, is the combination "@<marker-annotation> and @Advise" valid ? -- Alessio On Oct 3, 2013, at 5:45 PM, Alessio Gambi wrote: > 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
