Summary: | Configurable weaveinfo message inserts and expressing match constraints | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Andrew Clement <aclement> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | andrew.eisenberg, bouf10pub, neale, ramnivas, yang.meyer |
Version: | DEVELOPMENT | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows Vista | ||
Whiteboard: |
Description
Andrew Clement
2008-11-07 10:48:48 EST
I like the overall idea. I see a few issues, possible alternatives, and an additional use case: Issues: ====== 1. Weavers could come at many stages and we will need to somehow flag the "now do the march check" stage. For example, in state 1, an aspect library may be compiled with perhaps no matches. In stage 2, it may be woven into an application with some matches. In the final stage, an LTW may come into the mix to weave application server code with many more matches. 2. The annotation may need to have user extensions. For example, I may want to express that transaction advice match must not select any method in a class marked with @Repository annotation (almost real example from Spring applications). In such cases, I may need to provide an expression as a part of annotation value. A possible alternative: ====================== (Note that class and method names are just for facilitating discussion) If AspectJ could introduce a listener API, say WeaveListener, that can be set in a manner similar to -XmessageHandlerClass. The WeaveLister type can have methods such as: onAdviceMatch(MatchInfo mi). The MatchInfo may contain, an Advice element and matching info (matched element, runtime checks etc.). Advice could have methods such as getAnnotations(). A listener could then combine annotations such as @MatchCheck with the MatchInfo object. Developers could use any other annotations if they so choose and include whatever information they need (say, an expression), just use @AdviceName, or not use any annotation at all. Additional use case: =================== Such infrastructure may be used for integration tests to check if a advice matched the expected methods--something that every AspectJ developer asks at some point! First, I could implement WeaveListener to serialize all MatchInfo into a file, then load that data in a test, and make assertions over that information. class TransactionManagementAspectMatchingTest extends AbstractAspectMatchTest { WeaveData wd; protected void setUp() { wd = loadWeaveData("my-file.wd"); } public void testTransactionAdviceDoesntMatchRepository() { // get advice that is annotated with @AdviceName MatchInfo mi = wd.getMatchingInfoByAdviceName("txStart"); JoinPoint.StaticPart[] jpsps = mi.getMatchedJoinPointShadows(); for (JoinPoint.StaticPart jpsp : jpsps) { String typeString = jpsp.getSignature().getDeclaringTypeName(); Class type = Class.forName(typeString); if (type.getAnnotation(Repository.class) != null) { fail(); } } } } If such a listener can be implemented, this will greatly help integration testing. I like the idea as well. I see some benefits for tooling, particularly LTW tooling. A WeaveListener can be added by the eclipse debugger and can (for example): 1. Add gutter markers for the shadows of joinpoints woven at load time. Currently, there is a lack of editor support for LTW. This might address it. Alternatively, the weave need not happen at load time, but rather, the weaver can do a weave and throw away the result, while the WeaveListener keeps track of the matches as they occur. 2. Set weaving breakpoints (either when weaving occurs, or at locations that get woven). Would be nice to be able to set a breakpoint whenever a deow is reached, or when a pointcut is matched. The gutter markers depend on bug 268309. Looks like I'd better get the test cases for that patch sorted. unsetting the target field which is currently set for something already released |