Waiting for the release of Spring3, I have taken a look at the source code. There was an eternity that I didn’t that. My first insights where focused on the Expression Language (SpEL). When I discovered the @Value(“systemProperties[‘myProperty’]”) feature, I didn’t understand why it wasn’t more generally implemented to cover all spring managed properties those for which we used the PropertyPlaceHolderConfigurer. So I decided to make it.
It is a BeanFactoryPostProcessor that extends the PropertiesLoaderSupport the same base class as the PropertyPlaceHolderConfigurer utility. This post processor registers a bean that merges the declared properties and was exposed to the context of the SpEL which is simply the running container.
Given that properties can be accessed simply like this:
@Value("#{properties['property']}")
private String property;
where “properties” is simply the name of the registred bean and “property” is the name of the desired property. Note that the setter can be omitted in order to make the property immutable.
Where “environment” is a system property wich represents the application’s environment such as dev, staging or prod. In the example if the property is undefined the default value ‘dev’ is used.
You can find the entire source code here on gitHub. And if you want to simply see the BeanPostProcessor go directly here.
I appreciate the unitils framework and I used it in practically all the situations where I need an advanced tool for tests and especially integration ones. When I recently discover that a major version was released, I was enthusiastic to see what’s new in this version, especially since they suddenly pass from 1.1 to 2.0. But when I take a look at the official site of the framework, I found that the only significant change, of this major version, was a new mock module or framework!
Personally, and as a user of this tool, I hoped that the next version will be simpler to use, and especially more flexibly configured; because I dislike the fact that I was obliged to configure unitils modules similarly, for all the tests of my project. For example it isn’t possible to deactivate, activate or configure modules per test (more precisely test-class); so it wasn’t simple to use two test-database configurations (a real and a memory one); the database module leaks, also, a facility more flexible than the DbMaintainer. Because if you’re not using Hibernate and its hbm2ddl application, you must manage by yourself your database test schema, and it’s really boring especially for memory database based tests.
Instead of these enhancements, we have only a new mock framework, which I don’t think that I will use instead of frameworks like easymock or jmock, a more stable and reliable solutions. That’s why I believe that it’s time to move to the other option in this field which is Spring-test. In fact, Spring-test has not yet the same capability as unitils, but it’s really simple to extend; and this can be simply done by reusing unitils listeners (from the modules) as spring-test ones. Or to re-implement these features from scratch like it was done in the springdbunit project. Besides being a part of the popular Spring framework it will be surely enhanced and promoted to rich the status of the defacto choice of this category (unitils itself was promoted and made popular by an article on it’s spring-hibernate friendliness).
Not long ago, Spring was the main promoter of AOP technology and gave it its real place in the enterprise landscape. Recently and with the release of Spring-Batch, which is in his own as a framework the first one in this category for the java environment (I don’t know if there is any other equivalent in other platforms), Spring tends to promote one of the most powerful concepts in application development : Domain Driven Design.
DDD emergence difficulties
In fact, although DDD is not a ‘new’ concept (the famous Eric Evans’ Book was published in 2004, and Martin Fowler speaks about it in 2003), its adoption is not equivalent to its importance and added value. This is ‘classically’ due to the absence of real promoters which could put it into action and demonstrate its powerful approach for a wide public.
Indeed, DDD is rarely invoked publicly, and even when it is the case, it is promoted by some evangelists who preaches, in my eyes, by elitism which means that the concept is ignored and neglected by the masses. Besides, there have been no good and interesting examples of its application, for those who manifest their interest but have nothing concrete that can really demonstrate DDD. But the most principal obstacle (imho) is the harmful effect of the EJB design model and its related ‘patterns’, which is the actual main stream even for lightweight container based applications like Spring itself, and which promotes the anaemic domain model and the 'super’ service layer anti-patterns.
Spring-Batch: the savior?
By applying DDD in Spring Batch, we now have a realistic and elaborate example of concepts like ‘repository’, ‘factory’ or again the ‘ubiquitous language’. What’s also interesting in this implementation is that, by being a technical domain, developers can easily comprehend the concepts and identify them more easily. Talking about easiness, I noticed that a large number of people who have tried Spring-Batch find it a bit complex to use and they especially encounter some difficulties in finding the entry point to it. I think that this is due to the fact that they were accustomed to a traditional view of batch applications and haven’t taken the time to understand the way Spring-batch makes abstraction of all the common and traditional facets of a batch application.
I will not go into detail about what was done in this direction, because I think that it is very well treated on the official site or in the reference documentation or even in some online presentations, but I will say that by understanding the whys of this unusual way, we can realise all the powerful things that Spring-batch can offer.
In fact, to be simple and concise, Spring-Batch makes a very fine abstraction of a batch application and its execution flow and by doing so it permits not only the developer (or the user) to focalise on the specific steps of his job and their particular logic but also gives him a very powerful control facilities on what is done in these steps; for example, like the execution context which can hold information such as the number of processed items in any particular instant of the execution like a resource unavailability failure. Also note here, that it treats the steps in an item-oriented way which is one of the core reasons of these features and that’s why we must prefer it on the Tasklet solution which can be considered for refactoring legacy batches which cannot be easily adapted in the item-oriented way.
The Springframework new argument
Finally, and returning to the Springframework and the SpringSource, I just want to say that it seems to be that DDD will be the next Rod Johnson’s ‘War’ on EJB after the IoC one. And we can see that through the new features introduced into the 2.5 version, which takes benefits essentially from AspectJ power (and team!) to give technical solution to DDD patterns realisation; and also some presentations made by the Spring Team and essentially those of Rod Johnsonand Ramnivas Laddad. After all, even EJB ‘prone’ now the lightweight model promoted by Spring and the IoC pattern (without being able of course ☺ ), and Mr. Rod was obliged to find another area where EJB really sucks.
One of the common problems of using annotations as class markers, substituting configuration files for frameworks metadata is the processing phase of these annotations.
Even if this is not a big difficulty, problems, and potential bugs related to this task like those related to classpath scanning, and resources manipulation are significant and impose the use of low level frameworks like ASM or Javassist (to avoid class loading related problems) which are not very trivial to use nor well documented.
Fortunately Spring 2.5, provides a very nice framework which resolves ‘all’ these problems in a very clean way, using ASM under the woods. This is, more precisely, located in the core module which contains also the i/o and utilities frameworks and can be used without being in the context of using the whole spring container.
In fact, suppose that we have a custom annotation called Marker that have the attribute type. Now suppose that we want to scan the classpath and find all classes annotated by this annotation and having a particular value for the type attribute; In the following snippet of code I show how to satisfy this need.
Although Aspect Oriented Programming is a mature technology nowadays, it is not so widely used in enterprise applications, and this is, sometimes, due to the ignorance of the benefits of using it and the strength of its implementations or let’s say tools.
After being convinced to apply AOP, we must make a choice for the tool to use and the list of java frameworks as for almost all the areas is long. Fortunately this choice in our case is relatively easy (imho) because there are two predominant actors which are the most used and active ones and are AspectJ and Spring AOP. But even if I start by speaking about choices which traditionally means that I’ll compare the two solutions and make an exclusive choice (like for persistence, IoC…), I think that Spring AOP and AspectJ are two ‘opposite’/complimentary solutions that can coexist and interact without any problems. That's why in this particular case the real solution when applying AOP is to take in consideration the two tools and to make the choice based on the particular problem that we try to solve and its imposed context.
In fact the principal source of this opposition / complementarity resides in the nature of the two solutions; while aspectJ is a full AOP solution, based on class-weaving and is considered as a language on his own; Spring AOP is a relatively limited solution based on proxies and aiming to provide the Springframework the capacity to resolve with simplicity and transparency most commons enterprise application problems that are resolvable with AOP.
Being faced on a situation that we decide to resolve a particular problem or need with AOP, we must principally take in consideration three factors to determine which of the two tools, Spring AOP or AspectJ, to use:
The targets to be aspectized.
The type of pointcut needed by the aspect.
The invasiness of the solution.
So, firstly we must take on consideration the targets of our aspect, and this is due to two important facts that are the limitation of Spring AOP to act only on Spring beans and its incapacity to aspectise another aspect. Based on this it’s obvious that AspectJ is the solution in these cases.
The second consideration is to see what kind of pointcut our aspect needs; because Spring AOP can only be applied on method execution, whereas AspectJ can be applied on practically all types of possible pointcut (call, get, set, preinitialization, staticinitialization, initialization, handler, adviceexecution, withincode,…). This can be seen as a big limitation for Spring AOP but in reality method execution based pointcuts are the most used ones in common enterprise application problematics; and this is simply because the major part of code fragments having meaningful (or important) business or technical logics are put into methods so it’s obvious that aspects are tied to these methods and are simply an externalisation and factorisation of what was put in these methods before using AOP.
The third consideration is our tolerance to the invasiveness of the adopted solution. Spring AOP being a pure java implementation presenting an xml based declarative solution (schema-based support) and offering a valuable @Aspect support, is perfectly transparent. On the other side, being a class weaving based tool, AspectJ is relatively invasive. In fact if we choose the compile-time solution we must use the AspectJ specific compiler to weave the target application; even if this compiler has made many evolutions to be able of weaving source code as well as already compiled classes (or aspects - for aspect libraries) (this is also said post-compile weaving or binary weaving) even in a packaged form (for third party libraries or legacy applications) and its performance was remarkably optimized. Personally, and based on my own experience I think that even if transparency is an important consideration, its not so prohibitive to use compile time weaving, because after all, this consecutive ‘pollution’ is localized in the build relative part and not propagated in our code; and tools like maven or Ant offers a big support for these needs; then I think that independently of what tool or support to use, the most important here, and more generally for all problems of this type, is the good modularisation of our application. AspectJ presents also an alternative to compile-time weaving, which is the Load-Time weaving; this feature is more transparent than the traditional one and can be enabled in different ways, but it still an exotic solution that must gain more maturity to be used as widely as compile-time weaving.
There are also some miscellaneous considerations that can be important in some situations. As for other factors of discrimination these particularities are imposed principally by the natures of the two tools. In fact due to its proxy based implementation Spring AOP can presents some unexpected behaviour when faced to the use of the ‘this’ java keyword in the target method which can be a serious limitation when considerto use the developed aspects on legacy code or on third party libraries. Always for the same reasons, Spring AOP aspects can be instantiated only as singletons with the schema based support; and also as with the ‘perthis’ and ‘pertarget’ AspectJ’s instantiation model when using the @Aspect way; while the ‘percflow’ and ‘percflowbelow’ instantiation models are not yet supported. Then, there are performance issues; personally I never find a case where this issue was prohibitive for the use of AOP, and I’ll limit myself to mention the AWBench for those who want to make more investigations on performance.
Finally, and as a conclusion of what was mentioned above, I think that the best approach to take when we are faced to the problem consisting in to choosing what AOP tool to use between these two solutions, is to see firstly if we are in the applicability scope of Spring AOP (a spring bean as a target and a method execution as a pointcut); based on this we obviously must choose AspectJ in the case where we are out of this scope, else, I recommend using Spring AOP with the @Aspect support, which gives us the possibility of changing our initial choice and to use AspectJ if our needs evolutes and can’t be satisfied by Spring AOP.
