Bug 169014 - [ataspectj] DeclarePrecedence should allow declaring mutliple precedences
Summary: [ataspectj] DeclarePrecedence should allow declaring mutliple precedences
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Runtime (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-24 17:21 EST by Ramnivas Laddad CLA
Modified: 2013-06-24 11:07 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ramnivas Laddad CLA 2006-12-24 17:21:12 EST
Currently DeclarePrecedence has one String property. This makes it impossible to declare multiple precedence rules in an aspect. A simple, backward compatible fix is to modify the property type to String[] with each element representing a precedence rule.
Comment 1 Matthew Webster CLA 2007-01-04 09:53:40 EST
Can you give an example of what you are trying to do?
Comment 2 Ramnivas Laddad CLA 2007-01-04 10:12:01 EST
Here is what I was trying to do (using the change I suggest):
@Aspect
@DeclarePrecedence({"AuthenticationAspect, AuthorizationAspect", 
                    "PoolingAspect, LoggingAspect"})
class SystemCoordinator {
}

Generally, I try to follow the pattern (as recommended in AJIA), where the 
"regular" aspect themselves do no declare any precedence rules (that would 
cause code-tangling experienced in now-unsupported "dominates" construct). 
Instead, I write another "co-ordinating" aspect that specifies the 
precedence rules for aspects in my system.

Part of the issue is simply asymmetry between the code-style and @AspectJ 
syntax. In code-style, one aspect can include any number of precedence 
declaration. So the same thing should be possible with @AspectJ.
Comment 3 Matthew Webster CLA 2007-01-05 08:42:24 EST
Also as you have shown by having multiple statements you can be very specific about precedence e.g. there is no rule for Authentication and Pooling which could of cause be declare elsewhere.
Comment 4 Ramnivas Laddad CLA 2007-01-05 10:34:00 EST
I thought I should be explicit that after modifying the value attribute's type 
from String to String[] the current code will continue to compile without any 
modifications (i.e. no need to supply extra parentheses around the string value).
Comment 5 Andrew Clement CLA 2013-06-24 11:07:42 EDT
unsetting the target field which is currently set for something already released