Is it possible to configure AspectJ LTW solely in Java? I don't want to deal with XML, and I was wondering if I can do without it. I searched through AspectJ website, and I found only the XML way.
I am planning to use it with Spring, hopefully without any strange consequences(had enough problems already:)).
Thanks!
You can set up Spring to use AspectJ via LTW mostly using Spring annotations. But you do need META-INF/aop.xml because this is an AspectJ LTW requirement, it does not come from Spring. AspectJ is an independent technology which does not need Spring, Spring only supports it being used in its own context.
If you don't like XML for whatever reason - done right there is no problem and you only need to touch the file once - use CTW (compile-time weaving), e.g. via AspectJ Maven Plugin.
Related
This question already has answers here:
Spring AOP - why do i need aspectjweaver?
(5 answers)
Closed 7 years ago.
I'm reading spring documentation about AOP and now I'm at the section about using #AspectJ style.
Spring AOP is implemented in pure Java. There is no need for a special
compilation process. Spring AOP does not need to control the class
loader hierarchy, and is thus suitable for use in a Servlet container
or application server.
But in the section about #AspectJ style said
The #AspectJ support can be enabled with XML or Java style
configuration. In either case you will also need to ensure that
AspectJ’s aspectjweaver.jar library is on the classpath of your
application (version 1.6.8 or later).
As far as I know, aspectjweaver.jar performs the actual weaving of aspects at compile-time or load time. But Spring has its own proxy-based implementation. So I really don't see any reason for aspectjweaver.jar dependency.
That's true, to use #Aspect annotation we need aspectjrt dependency. But the dependency on weaver is not clear to me. Couldn't you explain in a nutshell how it actually works?
Spring AOP doesn't use the AspectJ weaver itself, but it reuses some of the classes from the aspectjweaver.jar file. It is used to define AspectJ-style pointcut expression, e.g. #Before.
I am using load-time weaving for a spring (2.5.x) project but I don't know what it is the purpose of it in general. I tried little googling but didn't find the upcoming pages useful. The only thing I understood is that it is something about AOP.
I noticed that it is used for older spring versions also wondering why is that?
Weaving is an AOP concept and it is the phase of integrating the aspects with the targeted code. After weaving, aspects are applied to the original code.
This process can take place in different times like compile and load. This article explains the different weaving times and LTW of AspectJ.
It says about LTW:
Load-time weaving (LTW) is simply binary weaving defered until the point that a class loader loads a class file and defines the class to the JVM.
The docs explain that, the LTW has to enabled either through the use of <context:load-time-weaver/> xml instruction or the use of #EnableLoadTimeWeaving annotation. However, I have done neither, but I still see that aspects are woven correctly in my projects!
In this case, I don't think they are woven at compile-time (but are they?), so it's surely got to be load-time-weaving?
Even if that's the case, how does it automatically choose to weave aspects in during load-time? Shouldn't the aspects remain unwoven if they are not turned on using one of the ways mentioned above as the docs say?
I've got the aspectj-weaver in my classpath, but that can't be enough to choose either of these weaving types anyway, can it?
Spring AOP does not rely on AspectJ byte code weaving. It just borrows the annotations used to define aspects from the AspectJ project. It is a separately implemented framework that uses run-time proxies to implement aspects. If you have <aop:aspectj-autoproxy /> in your application context then spring is using proxies to implement supported aspects defined on beans that are in the container.
Proxies can only achieve a sub-set of the full capabilities of the actual AspectJ system, basically advice that wraps methods. Due to their nature proxies have following limitations:
interception on external calls only (while breaching proxy boundary)
interception on public members only (private/protected can't be intercepted)
unawareness to local calls (or calls with this or super)
If you want to be able to advise fields for example, you would need to enable the use of Native AspectJ.
Spring MVC uses mainly annotations to configure its Controllers, as far as I know, the only way to configure a Controller in Spring WITHOUT Annotions (only XML) is extending the AbstracController (or Similar Controller classes) and currently all this classes are deprecated for Spring 3.
While I think that is a good idea to drop support for this classes, mainly because extending this classes creates controllers that hardly depend of Spring as a dependency, I don't understand why Spring doesn't provides a configuration like Struts Actions (Actions in Struts 2 don't extend any weird class so they dont' have any dependency of Struts)
Why Spring MVC doesnt provide a clean POJO-style configuration like Struts 2 Actions via XML?
Why to drop support for XML configuration on MVC using ugly Annotations? why not to drop it in ALL Spring Proyects?
The main problem with the XML/POJO approach is that there is no way to tell from looking at your code that special magic is going on.
Instead of seeing
#SomeAnnotation <<-- Oh, golly there is something special happening here.
java code...
You see
Java code <<-- special magic hidden in XML file (or not, no way to tell)
<<-- are these linked? no idea..
<<-- is something going on? let me go and search....
If changes happen to the source code, the XML may (or may not be) out of sync.
With the annotations you can update the java code and the spring annotations at the same time.
Yes it's cluttered but at least it's easy to sync the two.
Annotations are hard enough to grok when they're in your face. If they're not even visible the mental burden for us non-angry developers is really too much to bear.
why not to drop it in ALL Spring Projects?
Wouldn't that be sweet....
using ugly Annotations?
Obviously the question has been asked: Is there a way to hide annotations in Eclipse?
And the answer is: https://stackoverflow.com/a/2569646/650492
Sort of... does that help?
i am applying AspectJ in spring source tool
do i need to configure load time or compile weaving in spring source tool
i will be very happy if any provide details of using AspectJ for applying Aspect on Spring Source Tool
This is a very advanced topic, way beyond the scope of a single StackOverflow question.
Basically:
The simplest case is Spring AOP,
where you don't use AspectJ at all,
but create Java proxies from AspectJ
annotations. This is also the least
powerful option. Only a few pointcuts
are supported, and the targets must
be Spring Beans.
The most powerful option is static
AspectJ compilation, which you
usually integrate in your build
system (works fine with ant or
maven). Your class files are actually
changed to include the aspects. This
is called compile-time weaving.
Load-time weaving is somewhere
inbetween. You want to advise code,
but you don't want to change the
class files, so you "advise the
classloader" (this is not an adequate
definition, but it gives you an
idea). Loadtime-weaving is also
usually your only choice if you want
to add aspects to 3rd party library
code.
You should read AspectJ in Action by Ramnivas Laddad to understand all the subtle differences.
Either way, the settings you use in STS should reflect the settings you have in your build system. The section 7. Aspect Oriented Programming with Spring from the Spring Reference is also very helpful.