Matt RaibleMatt Raible is a Web Architecture Consultant specializing in open source frameworks.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: AngularJS, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Moving from Spring's XML to Annotations in AppFuse

Last night, I did a spike on AppFuse to change XML to Spring annotations (@Repository, @Service and @Autowired) in its service and data modules. While I was able to accomplish everything in a few hours (including converting tests), I did run into a couple issues.

AbstractTransactionalJUnit4..Tests vs. AbstractTransactionalDataSource..Tests
I've switched from my favorite Spring class to the annotation-happy AbstractTransactionalJUnit4SpringContextTests. However, this has presented an issue: when using ATDSSCT, I was able to call endTransaction() and startNewTransaction(). With ATJ4SCT, this doesn't seem possible. Below is a screenshot of the diff on a test method in the JPA implementation of UserDaoTest:

AbstractTransactionalJUnit4SpringContextTests vs. AbstractTransactionalDataSourceSpringContextTests

On the right, you'll notice that I had to comment out @ExpectedException to get the test to pass. This concerns me since this exception should be thrown. Is there a way to call endTransaction() and startNewTransaction() when subclassing AbstractTransactionalJUnit4SpringContextTests?

Instantiating GenericDao Implementations Programmatically
The second feature I tried to add is the ability to instantiate a GenericDao programatically rather than requiring a XML bean definition. In current versions of AppFuse, you can use the following bean definition to create a GenericDao for a model object.

<bean id="personDao" class="org.appfuse.dao.hibernate.GenericDaoHibernate">
    <constructor-arg value="org.appfuse.tutorial.model.Person"/> 
    <property name="sessionFactory" ref="sessionFactory"/>

When moving to a no-XML required architecture, it'd be nice to allow users to create GenericDao's programmatically. Below is the easiest way I've found to do this in a test:

GenericDao<User, Long> genericDao;
SessionFactory sessionFactory;

public void setUp() {
    genericDao = new GenericDaoHibernate<User, Long>(User.class);

However, there's a couple problems with this. First of all, mixing constructor injection and setter injection probably isn't a good idea. Changing the constructor to take a SessionFactory solves this problem, but now all subclasses need to have a more verbose constructor:

public UserDaoHibernate(SessionFactory sessionFactory) {
    super(User.class, sessionFactory);

Whereas before they had:

public UserDaoHibernate() {

In an ideal world, I could call new GenericDaoHibernate<User, Long>(User.class) and the SessionFactory would be wired in auto-magically. Is this possible with Spring 2.5?

The 2nd problem this presents is your client code will now be dependent on an implementation rather than the interface. I don't know how to solve that one, but I'd love to figure out a way to create GenericDaos with no XML and no implementation details in the client. Any ideas are most welcome.

If you'd like to see all the changes I made in converting from XML to Annotations, please see this patch.

Posted in Java at Nov 04 2008, 11:39:54 AM MST 14 Comments

hi Matt,

did you try the Spring testing framework? I've used in my last project and it seems to me that it really eases the process of performing integration testing... this is the url if you haven't seen it:

Posted by Patria on November 04, 2008 at 01:44 PM MST #

i'm in the same case i have an abstractDao:

public class AbstractPersistenceDaoGenericHibernate<T, PK extends Serializable>
        extends HibernateDaoSupport implements PersistenceDao<T, PK> {
    private Class<T> type = null;

    public AbstractPersistenceDaoGenericHibernate(HibernateTemplate hibernateTemplate){
    public void create(T newInstance) {

and my custom impl are like:

public class ClienteDaoHibernateImpl extends AbstractPersistenceDaoGenericHibernate<Cliente, Long> implements ClienteDao {

    public ClienteDaoHibernateImpl(HibernateTemplate hibernateTemplate) {

    public List<Cliente> getClientesByCriteria(Cliente clienteCriteria) {
        Criteria criteria = getSession().createCriteria(Cliente.class);
            criteria.add("nombre", "%"+clienteCriteria.getNombre()+"%"));
            criteria.add("direccion", "%"+clienteCriteria.getDireccion()+"%"));
            criteria.add("RFC", "%"+clienteCriteria.getRFC()+"%"));
        return criteria.list();

and finally in the test case:

public class ClienteDaoTest extends
        AbstractDependencyInjectionSpringContextTests {

    ClienteDao clienteDao;
    protected String[] getConfigLocations() {
        return new String[]{"PersistenceAppCtx.xml"};
    public void testClienteDao1(){
        List<Cliente> clientes = clienteDao.findAll();
        for(Cliente cliente:clientes){

I have some services that depends of this Dao and I have with JUnit4 like this:

public class TestClienteService {

    ClienteService clienteService;
    public void verificarEstadoInicial(){
        System.out.println("<!------------------------Antes de la transacción------------------------>");
    public void verificarEstadoFinal(){
        System.out.println("<!***********************Despues de la transacción************************>");
    public void pruebaClienteService1(){
        try {
        } catch (BusinessException e) {

Maybe this be useful for you, i'll hope so...

I don't have inconvenient with this way...


Posted by neodevelop on November 04, 2008 at 01:51 PM MST #

What's the name of that diff tool for OSX?

Posted by Jordi Bunster on November 04, 2008 at 03:25 PM MST #

@Jordi - it's IntelliJ IDEA. ;-)

Posted by Matt Raible on November 04, 2008 at 05:13 PM MST #


For programmatic creation and autowiring in combination, you can use @Configurable along with @Autowired, such as:

public class GenericDaoHibernate {

   private volatile SessionFactory sessionFactory;

In the Application Context configuration, you'll need to add the 'load-time-weaver' element in addition to 'annotation-config', and you'll need to provide a prototype-scoped bean whose type matches the programmatically created objects:


<bean class="appfuse.GenericDaoHibernate" scope="prototype"/>

There are a couple other requirements (AspectJ JARs, etc.) as described in the Spring 2.5.x Reference Documentation.


Posted by Mark Fisher on November 04, 2008 at 05:43 PM MST #

It is possible to use TransactionTemplate to test the transactions. See for more details.

Posted by Lukas Krecan on November 05, 2008 at 03:18 AM MST #

Hi Matt,

I've been meaning to try this, but haven't gotten around to it. To address the issue of client code depending on the implementation class, I think one possibility would be to eliminate the constructor params from the generic DAO. If Spring's autowiring goes as far as inferring the type parameters (see Spring's GenericTypeResolver) then you might be able to obtain the params like this:

//Default constructor with no args
public GenericDaoHibernate() {
   persistentClass = (Class<T>)((ParameterizedType)getClass().getGenericSuperclass()).getActualTypeArguments()[0];

Do you think this would work? I'd be interested to know if anybody has tried it.


Posted by Chris Herron on November 05, 2008 at 10:06 AM MST #

Any idea when Appfuse 2.0.3 will be released?

Posted by Marc on November 29, 2008 at 10:14 AM MST #

@Marc - I'm not planning on releasing 2.0.3. 2.1 is next on the roadmap. I hope to release it sometime in January 2009.

Posted by Matt Raible on December 10, 2008 at 10:38 AM MST #

Looking forward to it! Meanwhile, I'll play with the Snapshots.

Posted by Marc on December 10, 2008 at 10:44 AM MST #


Do you have any plans to switch client side validation to something annotation based?

Here is a good example in case you are curious.

Posted by Alex on January 12, 2009 at 06:39 PM MST #

@Alex - I don't mind switching to a annotation-based validation solution, but I'm not too keen on putting framework-specific annotations in model objects. I'd prefer to use standard annotations like those provided with JSR 303.

Also, your solution doesn't seem to provide client-side validation whereas AppFuse's current solution (Commons Validator for Spring MVC) provides both client and server-side validation.

Posted by Matt Raible on January 12, 2009 at 07:01 PM MST #

I'm trying to secure the managers and found that Spring Security has an annotation for this (@Secured only problem is that I can't get it to work. My guess is that I need some more configuration for the proxy beans to be generated with security interception. Any idea on how to achieve this?

Posted by Christian Decker on January 14, 2009 at 02:09 PM MST #

@Alex - I don't mind switching to a annotation-based validation solution, but I'm not too keen on putting framework-specific annotations in model objects. I'd prefer to use standard annotations like those provided with JSR 303. Also, your solution doesn't seem to provide client-side validation whereas AppFuse's current solution (Commons Validator for Spring MVC) provides both client and server-side validation. i think there is clientside validation with annotations. atleast that is what we have now.

Posted by tibi on August 06, 2009 at 02:03 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed