Summary: | Is there any particular order in ITD? | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Paulo Zenida <Paulo.Zenida> | ||||
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | aclement | ||||
Version: | 1.5.3 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Paulo Zenida
2007-01-05 11:17:11 EST
Created attachment 56542 [details]
Simple testcase
In the testcase the pointcut in Tracing matches methods with the @Include annotation. The DeclareInclude aspects adds @Include to HelloWorld.main() but only if it doesn't have the @Exclude annotation. If this annotation is added manually there is no match (as expected) but if added my DeclareExlude the @Include annotation _is_ added and the pointcut in Tracing matches. This would seem to be a bug i.e. DeclareInclude should _not_ add the annotation. In Matthews case there is a case of ambiguity that we don't currently recognize: public aspect DeclareExclude { declare @method : !@Exclude public void main(..) : @Exclude ; } public aspect DeclareInclude { declare @method : !@Exclude public void main(..) : @Include; } Both targetting the same method ... if the first one is processed first, the second one won't match. If the second one is processed first, they will both match. No precedence is specified - but even if it were I don't think it would make this work reliably (at the moment). This goes back to a long discussion on the hasmember() bug report relating to a proper ordering of processing ITDs and how to identify situations like this (see, for example bug 86818 comment #12 step 3) Hello there. Are there any news regarding this issue? I am working in a project, again, related to access control, and I am still facing some problems related to this bug. I have the following code in an Aspect called AccessControlAnnotationsInjector. declare @method : !@AccessControlled !@NotAccessControlled !private * (@AccessControlled *..*+).*(..) : @AccessControlledInherited; declare @method : !@AccessControlled !@NotAccessControlled !private * (@AccessControlled *..*+).*(..) : @AccessControlled; I guess the strange behavior of my client code (read strange here as random) is related to the order of the code injection. I suppose that, sometimes the second line is processed prior to the first one. When that happens, my method won't have the annotation @AccessControlledInherited, causing my application not to behave as expected. When the previous lines are in the same aspect unit, don't they execute always the same way? What I mean is, don't they execute in the order they are declared in the file? Thank you for your attention. I imagine the statements are added to a collection and due to them possibly being allocated in different areas of memory on each run, the order in which the collection is processed can change. So the behaviour is undefined. I suppose for statements like this from different files there should be an ambiguity error whilst for statements within one file we could use the defined ordering. and maybe declare precedence can help prevent the ambiguity error for the multiple file case. I agree with the behavior you specified: - "for statements within one file we could use the defined ordering" - "maybe declare precedence can help prevent the ambiguity error for the multiple file case" Have you any ideas if this will be implemented soon? At the moment, I have disabled the functionality in my project related to the injection of annotations. But I'd like to know if I need to rethink this functionality or if I can wait for updates on this issue. Thanks, once again, for your attention and quick feedback. Hi Paulo, I don't think it will be done soon, it needs more thinking. Bug 86818 (an old one) covers some thinking about doing the right thing for declares in the general case (see around comment 9 in that bug). unsetting the target field which is currently set for something already released |