Java Chimaera

comment signaler un incident

2011-01-15T13:47:00.000-08:00

Pour ajouter un point signalant un incident :

aller sur la map SECURITE TUNSIE : http://bit.ly/gox6Qm
chercher votre point en tappant l'adresse dans le moteur de recherche
un lien va apparaitre a gauche avec votre adresse appuyer sur "save to ..."
ajouter le point dans SECURITE TUNSIE et faites save

Courage, on confiance en vous.

Spring Expression Langage, a simple use case.

2009-11-03T13:56:00.000-08:00

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.

Besides, this gives me the possibility to use the EL feature to declare the locations of the properties files, to have another solution to resolve the “Complexity at the structural and dynamic level” (see this post : http://blog.springsource.com/2007/06/25/code-samples-from-springone-beyond-the-obvious-talk/).

For example I can define my files locations like this :

bean>

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.

Unitils 2: unitils is dead, long live to spring-test

2008-12-29T08:38:00.000-08:00

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).

Spring-Batch: Domain Driven Design in Action

2008-11-02T10:21:00.000-08:00

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 Johnson and 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.

Scanning classpath annotated classes with Spring 2.5

2008-10-12T12:32:00.001-07:00

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.

package example.annotation.scan;

import java.io.IOException;

import java.util.HashSet;

import java.util.Map;

import java.util.Set;

import java.util.Map.Entry;

import org.springframework.core.io.Resource;

import org.springframework.core.io.support.PathMatchingResourcePatternResolver;

import org.springframework.core.io.support.ResourcePatternResolver;

import org.springframework.core.type.AnnotationMetadata;

import org.springframework.core.type.classreading.MetadataReader;

import org.springframework.core.type.classreading.MetadataReaderFactory;

import org.springframework.core.type.classreading.SimpleMetadataReaderFactory;

import org.springframework.core.type.filter.AnnotationTypeFilter;

import org.springframework.core.type.filter.TypeFilter;

import org.springframework.util.ClassUtils;

/**

* Acts as a classpath scanner that finds classes annotated with

* the {@link Marker} annotation. It garantees that no scanned class

* is loaded by the {@link ClassLoader}.

* @author slim tebourbi

public class MarkedClassFinder {

private final static String FOLDERS_SEPARATOR_AS_STRING = System

.getProperty("file.separator");

* the base package wich represents the root of the scanned resources/classes folder.

public final static String BASE_SCANNING_PACKAGE = "base\\scanned\\classes\\";

private final Class<Marker> MARKER_ANNOTATION = Marker.class;

private final String TYPE_MARKER_ATTRIBUTE = "type";

private final MetadataReaderFactory metadataReaderFactory;

private final TypeFilter annotationFilter;

private final ResourcePatternResolver resourceResolver;

public MarkedClassFinder() {

this.metadataReaderFactory = new SimpleMetadataReaderFactory();

this.annotationFilter = new AnnotationTypeFilter(MARKER_ANNOTATION);

this.resourceResolver = new PathMatchingResourcePatternResolver(

Thread.currentThread().getContextClassLoader());

}

public Set> findMarkedClassOfType(String type) {

Set> markedClasses = new HashSet>();

* First of all we load all resources that are under a specific package by using a ResourcePatternResolver.

* By doing so we will use class files as simple resources without passing

* by the ClassLoader which can for example cause the execution of a static initialization block.

* It resolves also transparently resources in jars.

String candidateClassesLocationPattern = "classpath*:" + BASE_SCANNING_PACKAGE + "**" + FOLDERS_SEPARATOR_AS_STRING + "*.class";

Resource[] resources = null;

try {

resources = resourceResolver.getResources(candidateClassesLocationPattern);

} catch (IOException e) {

throw new RuntimeException(

"An I/O problem occurs when trying to resolve ressources matching the pattern : "

+ candidateClassesLocationPattern, e);

}

* then we proceed resource by resource, using a MetadataReaderFactory to create

* MetadataReader wich hides the ASM related interface and complexity.

for (Resource resource : resources) {

MetadataReader metadataReader = null;

try {

metadataReader = this.metadataReaderFactory.getMetadataReader(resource);

* the filter will pass only annotated classes

if (this.annotationFilter.match(metadataReader, metadataReaderFactory)) {

* the AnnotationMetadata is a simple abstaction of the informations

* that holds the annotation

AnnotationMetadata metadata = metadataReader.getAnnotationMetadata();

Map attrts = metadata.getAnnotationAttributes(MARKER_ANNOTATION.getName());

for (Entry attrt : attrts.entrySet()) {

if ((TYPE_MARKER_ATTRIBUTE.equals(attrt.getKey())) && (type.equals(attrt.getValue())))

{

String className = convertResourceToClassName(resource,BASE_SCANNING_PACKAGE);

try {

markedClasses.add(ClassUtils.forName(className));

} catch (Exception e) {

throw new RuntimeException("problems occurs when trying to load the annotated class : " + className,e);

}

} catch (IOException e) {

throw new RuntimeException("An I/O problem occurs when trying to process resource : " + resource,e);

}

return markedClasses;

}

static String convertResourceToClassName(Resource resource,String basePackage) throws IOException {

String path = resource.getFile().getPath();

String pathWithoutSuffix = path.substring(0, path.length()- ClassUtils.CLASS_FILE_SUFFIX.length());

String relativePathWithoutSuffix = pathWithoutSuffix.substring(pathWithoutSuffix.indexOf(basePackage));

String className = relativePathWithoutSuffix.replace('\\', '.');

return className;

}

AspectJ or Spring AOP?

2008-08-17T12:44:00.000-07:00

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 consider to 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.

The SPRINGSOURCE NEW PRODUCT

2008-05-01T12:00:00.000-07:00

SpringSource announced yesterday a new product the SpringSource Application Platform which is simply said a J2EE server à la Spring and OSGI.

From a technical point of view I am very pleased about this new product, because I believe in OSGI and its benefits. I'm working on IBM Websphere 6.1 which is also based on OSGI but without giving the opportunity to access the target runtime from the application level, a feature that could simplify considerably the management (versioning, deployment, patching ...) and the non-web modules of the application like batches. This is not only the case of Websphere but all actual implementations of J2EE application servers choose this approach.

But, from another point of view, I want to reply to a question that asked an interviewer to Rod Johnson about the unusual discretion about the announcement of this new SpringSource product.

I think that the days when Spring was an implementation of some great ideas of Rod that he published in his two famous books Expert One-on-One J2EE Design and Development and J2EE without EJB and evolved only by the needs and the critics of its community and those when the framework is becoming a platform with a company like the SpringSource behind it with important economic issues there is a big gap. And like any other company SpringSource will not be driven by the simple needs and ideas of his customers but principally by a commercial model. And so all the romantics and the effervescence of the Spring community must give way to commercial and economic models. I hope that I am wrong but I think that we are in the same scenario of Hibernate/Gavin King/JBoss.