> You're using two different ways of filtering what services you want advised. > Of course, I think this is a bug, as @Advise is being ignored. Tapestry > should apply both filters or raise an error when both annotations are used in > the same method.
> So don't use @Match! :D Why are you using it? Just curious. :) From the documentation (see http://tapestry.apache.org/service-advisors.html), it seems to be legal to combine the Advice and Match annotations: <quote> Starting from version 5.2, Tapestry supports annotation-driven advise methods. If the @Advise annotation is present, the advise method can be arbitrary named, as shown in the following example. By default, @Advise annotation applies the advice to any service matched by the @Match or marker annotations. You can limit the matching to a single service interface, as shown in the following example. @Advise(serviceInterface=MyService.class) @Match("*DAO") public static void byMatchAnnotation(MethodAdviceReceiver receiver) { ... } In the example above, the advice is applied to any implementation of MyService interfaces whose id matches the "*DAO" pattern. </quote> > I'd vote for misuse. :P Than the documentation should be updated. > Please try with just @Advise and let us know what happens. Using only the @Advise(serviceInterface = ServiceUpdater.class) seems to work fine, i.e., in my output console I actually see only the entry that I expect: >> ServiceUpdater: Receiver interface: >> at.ac.tuwien.dsg.cloud.elasticity.services.ServiceUpdater >> Advise update of at.ac.tuwien.dsg.cloud.elasticity.services.ServiceUpdater This however opens up another situation: I have the following build methods: 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 At the moment I adopted only 'workaround' to pass this point (see below) but I would like to implement the right solutions ;) Workaround: I changed the interface ServiceUpdaterCache to provide "similar" methods than ServiceUpdater without extending it so that @Advise works fine, and ignored OSServiceUpdater/AmazonServiceUpdater as only 1 is actually invoked. -- Alessio On Oct 2, 2013, at 1:23 PM, Thiago H de Paula Figueiredo wrote: > On Wed, 02 Oct 2013 05:06:34 -0300, Alessio Gambi <alessioga...@gmail.com> > wrote: > >> Hi, > > Hi! > >> @Advise(serviceInterface = ServiceUpdater.class) >> @Match("*") > > You're using two different ways of filtering what services you want advised. > You don't need @Match here, as you only want services that implement > ServiceUpdater. Please try with just @Advise and let us know what happens. > > Of course, I think this is a bug, as @Advise is being ignored. Tapestry > should apply both filters or raise an error when both annotations are used in > the same method. > >> At the moment, the ServiceUpdater interface is implemented only by one >> class, i.e., ServiceUpdaterImpl, but in the module I have two build* methods >> that have different dependencies injected: > > So you actually have two different services that implement the ServiceUpdater > interface. ;) > >> I know I can refine the condition inside the @Match annotation to something >> like "*ServiceUpdater" but I prefer to use the ServiceInterface.class as >> "filter". > > So don't use @Match! :D Why are you using it? Just curious. :) > >> Can someone shed some light here ? Is that a bug ? a misuse of the >> annotations ? > > I'd vote for misuse. :P > > -- > Thiago H. de Paula Figueiredo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
