We can use both #AspectJ annotation style to define aspects, as well as the AspectJ Java extension language, which requires us to use the ajc compiler.
What are the reasons that one would want to use the annotation style instead of ajc? It seems to me that a lot of functionality is given up by using annotation style, but not much (if anything) is gained, other than not having to use ajc (what's so bad about having to use ajc?)
Could someone please enlighten me on this topic?
Both styles (.aj and #AspectJ) have features that the other cannot do.
See this post for something the annotations can do that declarative AspectJ cannot: What is the AspectJ declaritive syntax for overwritting an argument
The .aj files for the most part (other than mentioned above) can do way more.
Most notable they can do ITDs (Inter-Type-Definitions aka adding methods and properties to classes).
The biggest reason you would want to use the #AspectJ is that it does not even require compile time weaving (CTW) or even load time (LTW) if you use Spring proxy AOP support. Spring will mimic #AspectJ but at runtime by creating proxies.
I have noticed that Spring, Eclipse (and myself) seem to be encouraging greater use of true AspectJ. I believe this is because the Eclipse plugin has gotten so good. Also with true AspectJ and the #Configurable annotation you can get Spring wiring on instantiated beans. This is how Spring Roo works.
With the Eclipse AspectJ IDE plugin you can see the pointcut references to both styles (# and aj) and get a very clear idea of what "magic" is happening.
Adding some additional step to your build process is not the easiest and good way. Especially when you have large project. You go away from all java tools and IDE support, which may not supports *.aj syntax.
Related
I'm working on a small project that determines code coverage when testing a java application. It basically consists of a plugin for an IDE which finds all the classes and methods in the project and saves them in a database, and an agent with aspectJ pointcuts that weave around all of these methods to log their execution.
The problem I have is that I only want to log the methods that are actually written by the developers of that very project and not those of underlying libraries. So the pointcuts need to be defined in a way that only methods of classes in the actual project packages are woven. On the other hand, since the agent is to be used with all sorts of projects, I can't hardcode those packages.
My attempt so far was to read all the package names from the database and build a string from that. Basically what it looks like is this:
private static final String POINTCUT_STRING = AspectUtil.buildPointcutString();
And then, when defining the pointcut:
#Pointcut(POINTCUT_STRING)
Thing is, this doesn't work because apparently when defining a Pointcut, the
Attribute value needs to be a constant.
So, how can I make it so that i can only weave methods in classes in the packages that I have in my database?
Thanks in advance, have a good one!
I don't think a dynamic aspect approach is going to work as aspectj does not expose the weaver to any state management or changes. Although this would be theoretically possible at runtime it's definitely not possible at compile time (and you have the option to add your aspects at compile time).
But to your issue...
What weave strategy are you using? compile or runtime? I've found compile to work very well and I'm not sure how to use runtime with aspectj. But what I can say is that if you use compile you'll only be weaving the application classes in any case as that is all you'll have access to.
Another comment to make is if you want to do something dynamic you'd be better off putting the condition on whether to monitor that method for code coverage downstream of the aspect. So when the aspect is executed the first thing it will do is decide if this class/method call should be monitored for coverage and then go on from there...
When I asked you:
What do you mean by "runtime weaving"? Load-time weaving (LTW) maybe? I.e. you are using aop.xml? I am asking for a specific reason.
You replied:
Yes, LTW. I am using an aop.xml file.
In that case you have the option of specifying pointcut definitions in aop.xml which is read during JVM start-up when the weaving agent is activated. For refererence, please read the AspectJ Developers Guide, there is a chapter on LTW. You will find sample code and sample XML definitions there, showing how you can extend an abstract aspect with an abstract pointcut in the XML file and specify a concrete pointut for a concrete subclass. That should give you the options you need to keep your pointcut out of the Java code, for whatever reason you think that's a good thing and you need it.
Please note that you cannot expect to modify aop.xml during runtime and re-load it, possibly re-applying the aspect dynamically to all classes. AspectJ LTW works in connection with class-loading, i.e. you only have one shot at JVM start-up before all application classes are loaded. This is not an AspectJ limitation but just how bytecode instrumentation in the JVM works.
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.
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...
I'm looking for some best practices when using Spring 3 annotations.
I'm currently moving to Spring 3 and from what I've read so far I see a lot of accent placed on using annotations and moving away from XML configuration.
Actually what is recommended is a mix of both styles, with annotations covering things that won't change often or from one run to the next (e.g. a #Controller will remain like that for the life time of the application), while the things that change and must be configurable go into XML (e.g. a mail smtp address, endpoints for web services that your application talks to etc).
My question is what should go into annotations and to what extent?
At which point annotations make things harder instead of easier? Is the technology (Spring 3) fully adopted as to be able to make such statements or does it take some more time for people to gain experience with it and then reflect on the issue?
It is always difficult to get real advanced information.
The easy tutorial with "look on my blog, I copied the hello word tutorial from Spring Source website... Now you can put fancy annotations everywhere, it the solution of all of our problems including cancer and starvation." is not really usefull.
If you remember right spring core had several purposes, among them:
to be non intrusive
to change any
implementation/configuration of a
bean at any time
to give a centralized and controlled
place to put your configuration
Anotation fail for all theses needs:
They introduce coupling with spring
(you can use standard anotation only
but as soon as you have at least one
spring anotation this is no longer
true)
You need to modify source code and
recompile to change bean
implementation or configuration
Annotations are everywhere in your
code. It can be difficult to find
what bean will be really used just by
reading the code or XML configuration
file.
In fact we have shifted our focus:
We realized that we almost never
provide several implementations of
our services.
We realised that being dependant of
an API is not that bad.
We realized that we use spring not only
for real dependancy injection
anymore, but mainly to increase
productivity and reduce java code
verbosity.
So I would use anotations when it make sence. When it is purerly to remove boilerplate code, verbosity. I would take care of using the XML configuration file for thing that you want to make configurable, even if it is only to provide a stub implementation of the service in unit tests.
I use #Value for properties that are configured in external properties file via PropertyPlaceholderConfigurer, as kunal noted.
There is no strict line for when to use xml, but I use xml:
when the bean is not a class I control
when the object is related to the infrastructure or configuration rather than to the business logic.
when the class has some primitive properties that I would like configurable, but not necessarily via externalized configurations.
In response to your comment: spring is very widely adopted, but "good" and "bad" are very subjective. Even my lines are not universal truths. XML, annotations and programmatic configuration all exists for a purpose, and each developer / company have their preferences.
As I said - there is no strict line, and no universal good practice for annotations.
Annotations are surely the way by which "newer" programming in java will continue. I use annotations for various uses...like #Scope for scope of bean, #Required for making dependency necessary, #Aspect for configuring advices,#Autowired for constructor injection using annotations. Since spring 2.5, annotation support has been good.
See here for spring tutorial, where annotation based issue are covered here.
I think that two cases that the usage of annotations could cause some problems. Firstly, if you want to write complex named queries (JPA) in your entities. I saw some entity code samples and asked myself whether the code is really java code or not. To many metadata in program code will reduce the readability of it which kills clean code principles.
Second problem is portability between JVM versions. Annotation is a feature 1.5+. If your software should support earlier JVM versions, then you may not use these.
Anyway, you can enjoy with annotations everytime without having any doubt and spare your time not changing IDE tabs to check XMLs if the property is still there or not, or entered correct etc.
For very small projects you could still XML version if you haven't too many stuff to be declared in spring. But, if you are in a huge project, the things could be very troublesome if you had 10 xml configs.
This will perhaps not help you much but at work they don't want to use autowiring because it needs a classpath scan (but that can be package-defined i think). So it increases the startup time of the application according to the size of the project.