This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Spring AOP vs AspectJ
I am reading spring reference document. In that it is written
If you need field access and update join points, consider a language such as AspectJ.
There are something that you can not do with Spring AOP, such as advise very fine grained objects (such as domain objects), AspectJ is the best case to work with it.
What is AspectJ compiler or weaver?
I did not get the meaning of above three points and hence confused. Please elaborate with simple example.
AFAIK Spring AOP doesn't support all functionalities of AspectJ, but only a limited set.
For example, Spring AOP supports only method-level pointcuts, so if you want fine grained control (i.e. field-level) you need to use AspectJ natively.
Your first point simply conveys that you can only apply point-cuts on method level, field interception is not implemented in spring-aop.
Next point tells that you cannot add advices on domain-objects(which are simple pojo entities),
The last is about weaving ,weaving is wiring of Aspects into objects in the spring XML file in the way as JavaBean. OR simply say, weaving is about adding new bytecode to your java class to make it usable to the framework.
also there is more important difference - AspectJ can inject AOP stuff at compile time(with aspectj maven pluging for example), spring AOP only at runtime using cglib or javasist according to the version of spring. However generally you would prefer spring AOP anyway - just because it much easier...
Related
I am doing a mock exam where I didn't quite understand one of the answers which lacked an explanation of why it was correct.
(Edited from here downward by kriegaex, adding the question from the below comment and some formatting and rephrasing in order to make the text a bit more coherent and readable.)
Question: "Which below statement is true about Spring's proxy feature?"
Answer: "There is a type of Spring proxy that can replace the object being returned by the method."
I understand that Spring AOP can use two types of proxies:
JDK dynamic proxies
CGLIB proxies
In my understanding these are the two type of proxies that are heavily used in Spring. For example when using #Transactional or when creating aspects (#Aspect).
What I understand of the answer given is that they are pointing at the #Around aspect. However, I don't understand why they call it a "type of Spring proxy". Is an aspect a proxy? Thus, is my understanding of an aspect making use of the JDK or the CGLIB proxies incorrect?
The question would be easier to understand if you had provided all possible answers, also the incorrect ones. But given the correct one (which really does sound strange), I can tell you the following:
Both JDK and CGLIB proxies serve the same purpose: to wrap and replace the original objects in order to be able to register some interceptors to their method calls, be it via Spring AOP or other methods.
Yes, both proxy types are used heavily in Spring, JDK proxies for classes implementing interfaces, CGLIB proxies for classes not implementing any interfaces. Optionally, you can configure Spring to use CGLIB proxies also for interface types.
There is no such thing as an "#Around aspect", only an #Around advice type (beside other advice types like e.g. #Before and #After).
No, an aspect is not a proxy. But Spring AOP uses proxies in order to implement its way of doing AOP via delegation pattern, as opposed to AspectJ which does not use any proxies but uses direct bytecode instrumentation to achieve its goal.
Find more information in the Spring documentation.
I am studying for Spring Core certification and I have a doubt related how Spring handle AOP.
Reading the documentation it seems to understand that exist 2 way to obtain AOP in Java:
Using AspectJ that using byte code modification for aspect weaving offers a full-blown Aspect Oriented Programming language. (so it seems to me that AspectJ is a differnt language that can be integrated with Java to offer it the AOP features).
Spring AOP: used in Spring framework that uses dynamic proxies for aspect weaving instead the bytecode modification.
So my doubts are mainly the followings:
1) Reading the documentations found the following method to add the AOP support to my Spring application:
USING JAVA CONFIGURATION CLASS:
#Configuration
#EnableAspectJAutoProxy
#ComponentScan(basePackages=“com.example”)
public class AspectConfig {
...
}
USING XML CONFIGURATION:
<beans>
<aop:aspectj-autoproxy />
<context:component-scan base-package=“com.example” />
</beans>
As you can see in both configurations there is a reference to AspectJ:
#EnableAspectJAutoProxy
and
<aop:aspectj-autoproxy />
Why? If Spring use Spring AOP instead AspectJ why there is a reference to AspectJ when I configure AOP in Spring?
2) In the previous examples are show 2 way to configure Spring: by Java configuration class and by XML configuration. I know that exist a third way to configure a Spring application: by the use of annotations. So exist a way to configure AOP using the annotations?
I think that these Spring AOP settings with references to AspectJ in their names are indeed more irritating than helpful. I can understand why you are confused. Spring AOP is really a different concept from AspectJ. As you said: dynamic JDK or CGLIB proxies in Spring AOP versus byte code instrumentation during compile or load time in AspectJ. Other differences are:
AspectJ compile-time weaving needs a special compiler called Ajc. It is basically an Eclipse Java compiler Ecj enhanced by the aspect weaver which does the instrumentation. In contrast, Spring AOP creates dynamic proxies during runtime.
In AspectJ there are two syntax variants: native and annotation-based. The former is more elegant and expressive, a superset of Java and definitely needs Ajc to be compiled. The latter uses Java annotations and can be compiled with Javac, but needs the aspect weaver contained both in Ajc (compile time) and in the weaving agent aspectjweaver.jar (load time) to "finish" them and make them usable during runtime. Both variants need the AspectJ runtime contained in both aspectjrt.jar (very small, used for compile-time-woven aspects during runtime) and aspectjweaver.jar (much bigger, used for load-time weaving, contains both the runtime and the weaver).
AspectJ works for any Java class, it does not need or even know about the Spring framework. Spring AOP needs the Spring framework as a foundation, you can only instrument Spring Beans/Components with it, not Spring-agnostic POJOs.
AspectJ is more efficient because it avoids proxies. But Spring AOP is an optional part of the Spring framework anyway, so if you use Spring and method execution interception of Spring Beans is all you need, it makes perfect sense to use it.
Spring AOP uses a subset of the AspectJ pointcut syntax. Maybe this is the subtle reason why Spring AOP uses AspectJ references, but I still think it was a bad decision to not differentiate the two concepts from one another more clearly with regard to nomenclature. Besides, the common poinctut language subset is defined in a little JAR called aopalliance.jar because long ago a so-called "AOP Alliance" has defined that syntax. The dominating and by far most powerful AOP language today is AspectJ, though, so in reality AspectJ (maintained by Eclipse) is the leader in that area, IMO.
When I say that Spring AOP uses a subset of AspectJ syntax, conversely it means that AspectJ offers a superset. There are more pointcut types such as call(), set(), get() etc. and you have way more options to intercept joinpoints and apply cross-cutting concerns to your code base via advice or inter-type definition.
I do not understand your question #2. The configuration class in your example does use annotations, so there is no third way. ;-) But there is an old, really outdated AOP approach in Spring called interceptors. It is a leftover of an early AOP approach and kind of obsolete nowadays, even though it is still usable.
Both Spring AOP and AspectJ can be configured via XML or annotations within Spring. :-)
Not sure if I completely understand your question, I think you are asking something like: "If I'm using Spring AOP, why do I see references to AspectJ?"
If that's the case, you should know that Spring is not in competition with AspectJ, but rather leverages AspectJ for AOP.
See Spring documentation: http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/aop.html
I'm looking for a way to add certain functionality to JAX-RS resources in an OSGI environment. Annotations seem to be a clean way to do this and I've seen it done in the Spring framework (no experience). Annotations such as #Transactional, or (what I wanted to do, requires a permission flag to be set on a user) #Permission(CREATE). However, I'm a bit stuck on how to do this in an OSGI environment.
The normal way(is it?) to go about adding aspects would be to register an aspect service that wraps the original service. If I looked it up correctly, JAX-RS resources are tracked and hooked up to an HttpService. JAX-RS resources do not implement an interface and proxies would need to be dynamically created.
How would I dynamically generate OSGI aspect services/resources that effectively hide the original resource from the JAX-RS tracker that hooks it to the HttpService? I have zero experience with existing AOP frameworks and barely any knowledge of AOP itself.
It is very common in the Java EE and Spring world to use interceptors and define additional behavior based on annotations. There are some solutions in OSGi as well, there is an RFP to support EJB annotations.
However, I have a different opinion. Although this looks cool, it is also magical. See the "Why not annotations, interceptors and other magic?" chapter of this README file where I wrote down my reasons. This project implements the logic that you would like to achieve with #Transactional annotation, but it only uses functional interfaces.
I think it is better to think in lambda expressions to achieve the goal you want (see the java 8 example behind the link). If it is not Java 8, you can still use anonymous classes (see jave 7 and above example behind the link). Your code will look more ugly with anonymous classes, but it will be very clear, what your code does.
Others might not like my answer. Three years ago I was one of the biggest fan of annotation scanning, weaving and interceptors. After a couple of headaches, I became an enemy of this "magical" concept.
There is a Swing based multilayer Java application, each module has its back-end and front-end.
Now we want to add security using Spring Security. We have decided not to use AspectJ because of its overhead.
Is it possible to somehow inject the Spring method call authorization to Java Security Manager so that every method call in the back-end is intercepted (or delegated to) by the annotation-based model of Spring Security?
Note:
The application contains a huge number of packages and the objects are instantiated using new operator or by reflection techniques. It is not possible to revise all instantiations and change all objects to Spring beans. Java Security Manager intercepts all method calls regardless of how the object is constructed. This is the reason we need to inject somehow Spring Security Method authorization to Java Security Manager.
Using Spring AOP does not require AspectJ, so as long as you configure your application using Spring you should have no problems using the native JDK support (it's the default anyway). I'm not sure if you tried it and it didn't work for you, so maybe some more specific information in the question would help here.
Java Security Manager is probably a needless distraction, but maybe if you could explain what you meant to do with that in some more detail it might help as well.
And, by the way, I'm not sure what the overhead is that you mention with AspectJ, but if you think it's significant I would recommend testing first because it certainly isn't a big difference at runtime for most applications. It can even be faster than other approaches.
I've been using spring for some time, but I always wondered how does it work, more specifically, how do they load and weave beans/classes marked only with an interface or #annotation.
For the xml declarations, it's easy to see how spring preprocesses my beans (they are declared in the xml context that spring reads), but for the classes marked only with annotations, I can't see how that works, since I don't pass any agent to the jvm or so.
I believe there is some Java/JVM hook that allows you to preprocess classes by some sort of criteria, but I wasn't able to found out anything on the docs.
Can someone point me to some docs? Is this related to the java.lang.instrument.ClassFileTransformer API?
Actually by default Spring does not
do any bytecode postprocessing
neither for XML-, nor
annotation-configured beans. Instead
relevant beans are wrapped into dynamic
proxies (see e.g.
java.lang.reflect.Proxy in the
Java SDK). Dynamic proxies wrap the
actual objects you use and intercept
method calls, allowing to apply AOP
advices. The difference is that proxies are essentially new artificial classes created by the framework, whereas weaving/bytecode postprocessing changes the existing ones. The latter is impossible without using the Instrumentation API you mentioned.
As for the annotations, the implementation of <context:component-scan> tag will scan the classpath for all classes with the Spring annotations and create Spring metadata placeholders for them. After that they are treated as if they were configured via XML (or to be more specific both are treated the same).
Although Spring doesn't do bytecode postprocessing itself you can configure the AspectJ weaving agent that should work just fine with Spring, if proxies do not satisfy you.