You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Igor Drobiazko (JIRA)" <ji...@apache.org> on 2011/04/20 10:05:05 UTC
[jira] [Commented] (TAP5-1510) The @Advise annotation limits advice
to just a specific interface type
[ 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