[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Re: [aspectj-dev] aspect keyword != @Aspect ?
|
Thanks Wes for the explaination.
It makes total sense that the annotation based pure java style aspect would compile into something different. That statement on the next page about the aspect keyword and @Aspect can be a bit confusing if you don't take a minute to stop and think about how it must be working (like I didn't :] ). I think It might make sense to update the documentation I refered to define equivalence in as semantically equaivalent but implemented differently, or have a footnote with a link to the whats different.
As for the build step, I think you're probably right and I've got something wrong. But I'm not sure what I'm not doing correctly. I compile the aspect into a jar by itself:
<!-- trimmed down to the illustrate the basic usage, not the actual build.xml -->
<iajc
source="1.5" target="1.5"
outJar="myaspect.jar"
XterminateAfterCompilation="true">
<sourceroots>
<pathelement location="aspect"/>
</sourceroots>
</iajc>
Later, I run iajc again to apply the aspect to a simple HelloWorld example:
<iajc
source="1.5" target="1.5"
outJar="example.jar">
<aspectpath path="myaspect.jar"/>
<sourceroots>
<pathelement location="example"/>
</sourceroots>
</iajc>
Then I run the app with both jars on the classpath that I'll hit that NoSuchMuchException I described before. I've also tried a variation where I just did it all with one iajc task and put the aspect and example sources into the sourceroots element, but got the same results.
Is there an option that says weave annotation style aspects? I didn't notice one.
Are there any examples the demonstrate compile time weaving an annotation based aspect?
-
Eric
Wes <wes@xxxxxxxxxxxxxx> wrote:
Hi Eric -
Thanks for a well-worded question; you put a lot of work into the investigation.
Overall, annotation-style and code-style aspects should be semantically the same, subject to the exceptions mentioned in the documentation (including the aspectOf() method) and subject to any bugs in implementing annotation-style. However, there is no guarantee that code-style and annotation-style are implemented the same way. If the annotation-style aspects didn't apply at all, I would suspect mistake in the build configuration for that aspect.
The documentation on @AspectJ style aspects describes some differences from code-style aspects, including the aspectOf method:
(See also exceptions for proceed(), privileged, thisJoinPoint, etc.)
We recommend against decompiling to understand AspectJ semantics because the implementation techniques can vary between releases or styles of AspectJ and because it's hard to do. More often than not, users find "problems" -- things that shouldn't work (but actually do) -- because they misinterpret the bytecode. In this case, you found a true difference in the aspectOf() method, but one which would have been easier to understand as an exception from reading the documentation.
(This is not to say the documentation is easy to read or complete; please let us know when/where it isn't.)
Thanks -
Wes
------------Original Message------------
From: Eric Crahen <eric_crahen@xxxxxxxxx>
To: aspectj-dev@xxxxxxxxxxx
Date: Fri, Aug-4-2006 8:11 PM
Subject: [aspectj-dev] aspect keyword != @Aspect ?
I'm having difficulty understanding the difference between the aspect keyword and the @Aspect annotation. According to the documentation the aspect keyword and the @Aspect annotation are the same. In practice, this seems not to be true; or I am making a giant mistake.
http://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj.html
"The use of the @AspectJ annotations means that there are large classes of AspectJ applications that can be compiled by a regular Java 5 compiler, and
subsequently woven by the AspectJ weaver (for example, as an additional build stage, or as late as class load-time). In this chapter we introduce the @AspectJ annotations and show how they can be used to declare aspects and aspect members."
The example on the next page reenforces this notion:
"The declaration: @Aspect
public class Foo {}
Is equivalent to:
public aspect Foo {}
"
So that's why I think these two methods should produce equivalent results, below is why I'm finding they do not:
The two simple examples show below do not produce equivalent output. Its easy to see after building each separately and dumping the class signatures with javap, its easy to see there are lots of generated methods added to the TestAspect.class from sample #1, sample #2 on the other
hand doesn't contain any of these things.
// Sample #1
// TestAspect.java
public aspect TestAspect {
@Pointcut("execution(* *(..))")
public void pc() {}
@Before("pc()")
public void beforePc() {
}
}
// Sample #2
// TestAspect.java
@Aspect
public class TestAspect {
@Pointcut("execution(* *(..))")
public void pc() {}
@Before("pc()")
public void beforePc() {
}
}
If I take it a step further and actually apply the aspect to a simple HelloWorld example with the compile time weaver. The first version using the keyword runs just fine. Dumping the code with javap I can confirm that the aspect was woven into the class. The second version using the aspect does not work. The HelloWorld program references methods that are not actually generated for the aspect version (TestAspect.aspectOf() for
example).
I haven't attempted load time weaving, but I will not be using this in my appliciation.
I am building this all with the iajc ant task.
Can anyone explain what I'm doing wrong?
- Eric
See the all-new, redesigned Yahoo.com. Check it out. _______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
- Eric
Yahoo! Music Unlimited - Access over 1 million songs.
Try it free.
