[ https://issues.apache.org/jira/browse/TAP5-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022014#comment-13022014 ]
Igor Drobiazko commented on TAP5-1510: -------------------------------------- It makes absoutely sense to change the logic of matching the service iterface to use: markable.getServiceInterface().isAssignableFrom(serviceDef.getServiceInterface() Regarding @Match: At the time of implementing @Advice or @Decorate annotations it made sense to me to ignore the @Match annotation when @Advice or @Decorate is present. For example in the following code you need to decide how to match the service: either by its service id @Match("Bla") @Advice(serviceInterface=Foo.class) public static void bla(...) { ...} But if we change the serviceInterfac() attribute of @Advice or @Decorate annotations to default to Object.class, then we could come up with something like: DefaultModuleDefImpl: private <T extends Annotation> String[] extractPatterns(Class serviceInterface, String id, Method method) { if(serviceInterface != Object.class) return new String[]{}; Match match = method.getAnnotation(Match.class); if (match == null) return new String[] { id }; return match.value(); } What does it mean? If you didn't provide the service interface for @Advise or @Decorate, then you probably want to match by id. On the other hand, if you want to match a specific service interface than, @Match should be ignored as it doesn't make sense. The alternatives would be: @Match("Bla") @Advice public static void bla(...) { ...} @Advice(serviceInterface=Foo.class) public static void bla(...) { ...} Does it make sense? > The @Advise annotation limits advice to just a specific interface type > ---------------------------------------------------------------------- > > Key: TAP5-1510 > URL: https://issues.apache.org/jira/browse/TAP5-1510 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-ioc > Affects Versions: 5.3.0, 5.2.5 > Reporter: Howard M. Lewis Ship > > @Advise requires that you specify a service interface (there's no default > value). This is much more limiting than the advise method naming prefix, > which will match all services (subject to the use of @Match), without regard > to service interface. > Further, inside ModuleImpl: > private boolean markerMatched(ServiceDef serviceDef, Markable markable) > { > if > (!serviceDef.getServiceInterface().equals(markable.getServiceInterface())) > return false;; > here, the Markable is the AdvisorDef2 instance generated from the @Advise > annotation. This is an exact comparison; I believe this should be: > if (! > markable.getServiceInterface().isAssignableFrom(serviceDef.getServiceInterface())) > return false; > That, combined with a default of Object.class for @Advisor.serviceInterface > would do the trick ... the @Advise.serviceInterface acts as an umbrella over > any services' service interface. > ..... ok, did more research and more stepping with the debugger. The above > should be fixed, but it's only the second case of matching, the primary match > should be based on the @Match annotation ... but that's broken too: > Frrom DefaultModuleDefImpl: > private <T extends Annotation> String[] extractPatterns(T annotation, > String id, Method method) > { > if(annotation != null) > return new String[]{}; > > Match match = method.getAnnotation(Match.class); > if (match == null) > return new String[] > { id }; > return match.value(); > } > Here, the annotation is the @Advise annotation; I don't get why it returns > empty string array; we should still see if there's a @Match annotation. > Looking at the code, I can't see any reason why we would return that empty > string array, the presense of the @Advise annotation (or for a decorator > method, the @Decorate annotation) has no purpose I can figure out. > In my situation, my advise method was not invoked because > a) Primary check (by service id) failed, because the @Match annotation was > ignored > b) Secondary check (by service type and marker annotations) failed, because > of inexact match on service interface > So, the end result is the @Advise is only useful to advise a specific service > interface, which is the opposite of what method advice is about ... it's > supposed to match against a swath of services, adapting the advise to > whatever methods are present in those services. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira