Spring Testing Survival guide

If you have an application with thousand of beans, you must do unit testing but…Spring testing is boring, belive me.
A very complex Spring application usually have a lot of dependency: I had to manage over 3000 beans definitions in a production project right now.
Sometimes you want only to test a bit of it, and setting up a complete Spring Context will drive you crazy.
To avoid losing mind, my suggestion is to …cheat. Let’see how.
Continue reading “Spring Testing Survival guide”

Why your IoC container could be a pain for you, young Padawan

Inversion of Control (IoC) is a very good idea.

But as the clever Joel Spolsky  noted, sometimes you need to be a super-natural hero to use it:

I try not to be judgemental (HAHA!), but I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren’t as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It’s the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don’t understand it.

I have trouble using Spring in at least two projects. On the third, it was a disaster, because a single software-architect-guy keeps passing around the Spring context factory as method parameter, getting beans from it!

Continue reading “Why your IoC container could be a pain for you, young Padawan”

April 0.2 Application Performance Framework

April (Application Performance Framework) is a super-light application framework based on Spring, featuring:

  • An Aspect Oriennted Programing Performance Monitor, which try to increase performance on the fly
  • A super-light XML-RPC communication framework

April first commitment is “be lite, be pluggable” and do not re-invent the wheel.
I am happy to describe here how it works the Beta 0.2, called “Fat Cat” by friends.

Getting Started with April

April is a self-contained package, you can download here:

[download id=”3″]

April project has been developed under Eclipse Ganymede, which is higly recommended. Anyway an ant build script is provided.

The project binary results in a webapp (war) you can deploy under your preferred application server.

How it works

The april demo is composed of a FileMonitor utility used to monitor file changes across a file system.

The core of April is the PerformanceMonitor, which is an aspect configured via Spring: take a look to the aopMonitor.xml located under april/war/WEB-INF/spring/ folder.

The performance monitor will start measuring the performance of every methods defined in the pointcut. When one method is too slow, the Performance Monitor will check if the method belongs to a class implementing the “AutoTune” interface.

If the AutoTune interface is implemented, the PerformanceMonitor will ask to the object if it can be opttimized via a call to

public boolean canBeOptimized();

If the method returns true, Performance Monitor will begin the optimization phase.

The optimization phase

The Performance monitor will invoke the following method of the AutoTune interface

public Runnable split() throws Exception

Is up to the implementation to return a new runnable object, which will do a part of the work.
The returned object need not to be of the same type of the AutoTune implementor  (ATI).

The idea behind

The idea is to find bottleneck based on how much time a method takes to run. The monitor then asks to a slow instance to spawn another thread.

This approach cannot solve every issue, but it seems effective on some scenarios, because it can “follow”  the bottlenecks when they change position.

The call is performed before the return statement of the “slow” method, and a global lock is used to guarantee only one spawn request at the time.

The post-optimization phase (speculation)

This phase is fired via the AutoTune method

public void mergeWith(AutoTune candidate2);

but it is still unfinished and unstable, so it is disabled for the meantime.
I am evaluting different approaches, and every comment is welcome.

Do you like April? Do you have an idea for improving it? Leave a comment below!

Release History

  • April 0.2 is the first full english release.
  • April 0.1 was a “request for comments” release, published in this italian article. It was released on April 8th , 2009

Java in un Espresso, Parte III: April

Nei precedenti articoli abbiamo visto come creare un applicazione Java agile, evitando il blasone delle specifiche J2EE. Dopo aver valutato (scartandola) una soluzione 2-tier molto simile a quelle fattibili in PHP, ci siamo focalizzati su una soluzione basata su Spring.

Come test, abbiamo sviluppato a Gioorgi.com una applicazione didattica che abbiamo chiamato “April”.

April si serve di Spring e AspectWerz per mettere in pista un semplice monitor di file, che gira all’interno di una webapp. Le performance del file monitor sono misurate tramite un bean chiamato PerformanceMonitor, che è istrumentato tramite Aspetc Oriented Programming.

Il risultato è che il sistema crea un numero di thread variabili a runtime, finché i tempi di risposta del FileMonitor non si avvicinano a quelli richiesti dalla configurazione di Spring.

Il Performance Monitor ha dei limiti sul numero di thread che può creare, per evitare di sovraccaricare il sistema.

Inoltre pochissimo codice (circa cinque classi su una trentina) hanno riferimeni a interfacce Spring (per lo più per supportare la creazione di oggetti che siano gestibili con l’AOP di Spring).

April è un buon esempio di una applicazione strutturalmente semplice, che fa una cosa abbastanza complicata. Non sarebbe stato facile sviluppare April in un linguaggio di scripting, né sarebbe stato facile ottenere le performance che ha, come vedremo.


April sfrutta l’autowiring in modo semplice, per istanziare (e monitorare) degli startup task.

Contrariamente alle servlet, i task non devono essere servlet: è sufficiente che implementino una maker interface chiamata StartupTask.

Nel file di configurazione di Spring, vengono dichiarati i task di startup, che Spring provvederà ad istanziare per conto nostro. Inoltre Spring “inietterà” tutte queste istanze in una particolare collezione tipizzata che si trova in una classe chiamata “Startup”.

Al boot, viene creata una sola istanza di Startup da parte di Spring, e questa classe si occupa di creare un thread per ogni istanza che implementa l’interfaccia StartupTask.

Potete scaricare April da questo link: [download id=”2″] … e restate in ascolto!


April è stato proavto sia sul jdk 1.5 che sul jdk 1.6. Come si sa, cambiando versione di JDK le performance migliorano in modo apprezzabile. In particolare il JDK 1.6 si è dimostrato molto più veloce nella gestione dei file (è quasi dieci volte più veloce nella scansione degli oggetti file). Rispetto al vecchio jdk 1.4, la concorrenza è gestita in modo molto più efficace, ed è stato possibile raggiungere livelli di parallelismo dei thread molto spinti, semplicemente con un uso accorto delle zone di sincronizzazazione