DDevelopment & Design

Hibernate annotations + Spring transactions in OSGI

  • bympr
  • May 23, 2010
  • 3 minute read

On our new project we decided to develop backend as services deployed on Servicemix 4.2. To make it easier for developers more familiar with ‘traditional’ web applications based on spring+hibernate stack it should (at least partially) resemble such application. Therefore, we want to have following bundles:

  • model –  containing hibernate classes
  • dao – implemented using hibernate template
  • service – interfaces for bundles implementing webservices, also controlling transactions, validation and similar stuff

So far, so good. Additional requirements are:

  • hibernate is configured using annotations
  • we use declarative transaction management with spring @Transactional annotation

Now, the question is – how to achieve it in OSGI environment? There are some tutorials on the web, but I haven’t found anything about this particular configuration, so I want to share our solution – as it wasn’t as straightforward as one might expect.

Hibernate bundle

The very first problem was the structure of hibernate jars themselves. It turned out that simple

wrap:mvn:org.hibernate:hibernate:3.3.1.GA

is not enough when one wants to use annotations. The problem is that both hibernate-core, and hibernate-annotations are using same package, namely org.hibernate.cfg. This is pretty anti-OSGI design, as OSGI bundle can use package exported by exactly one bundle.

The solution is of course pretty simple – we have to create our own bundle, which embeds both hibernate jars. This can be achieved with following maven-bundle-plugin configuration:

          

    *;uses:="org.hibernate";version=3.3.1.GA
    !*
    *;scope=compile|runtime;type=!pom;inline=true

Of course, you have to add hibernate dependencies to pom.

Session factory and transaction management

Servicemix has its own JTA TransactionManager, and at first I wanted to use it for managing our hibernate transactions. Unfortunatelly it turned to be somewhat tricky, so I decided to use simple solution, i.e. org.springframework.orm.hibernate.HibernateTransactionManager. It is declared in our dao bundle and exported as OSGI service:

	

    org.springframework.transaction.PlatformTransactionManager

Then, in service bundle we import it, and configure declarative transactions:



So far, it doesn’t look much more complicated than in traditional, monolithic war application. But there is one more caveat:


org.hibernate.jdbc.ConnectionWrapper is not visible from class loader


At first I thought it’s a matter of some misconfigured import/export declarations in some of our bundles. However, after some googling it turned out that it’s Hibernate’s bug


It is caused by using Thread context classloader when obtaining connection. It looks that the bug itself is already fixed, but we didn’t want to change to Hibernate 3.5 just because of that.


It turns out that there is quire simple workaround – you just need to make Spring aspect that will set context classloader to proper one (i.e. bundle class loader) before opening hibernate session, and you’re done. But again, using Servicemix makes it slightly harded, as it turns out that using @AspectJ style poses some difficulties (see e.g. this thread).


But it turns out that there is pretty simple solution – use old, Spring 1.x-style aspects :). This requires a bit more boilerplate xml, but at least we got it working pretty quickly.


The aspect class, setting proper classloader:


public class AspectFix implements MethodInterceptor {

    public Object invoke(MethodInvocation invocation) throws Throwable {
        ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
        Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
        try {
            return invocation.proceed();
        }
            finally{ Thread.currentThread().setContextClassLoader(contextClassLoader);
        }
    }


The xml config:



      .*

    *Service

      fix


Final remark – now the service bundle has to import org.hibernate.jdbc to make it all work – as its classloader is used to initialize connection now.


To sum up: this is definitely not the most elegant solution one can imagine- but it’s working.


		

		





	


			

			

				

					
				

				

					

						
							
						
					

					

									

			

		

	
	








	


				

			
	



					

						
					

						

							 — Previous article
						


						

							Introducing camel-drools component						

					

				
							
					

						

							Next article — 
						


						

							Apache ODE 1.3.4 released						

					

				
				

		


			


				
				

					

						You May Also Like					

				


				


					


	

		
DDevelopment & Design

		
		

						

				
How to use mocks in controller tests
			


							

											

							
Even since I started to write tests for my Grails application I couldn't find many articles on using mocks. Everyone is talking about tests and TDD but if you search for it there isn't many articles.
 
Today I want to share with you a test with mocks for a simple and complete scenario. I have a simple application that can fetch Twitter tweets and present it to user. I use REST service and I use GET to fetch tweets by id like this: http://api.twitter.com/1/statuses/show/236024636775735296.json. You can copy and paste it into your browser to see a result.
 
My application uses Grails 2.1 with spock-0.6 for tests. I have TwitterReaderService that fetches tweets by id, then I parse a response into my Tweet class.
 

class TwitterReaderService {
    Tweet readTweet(String id) throws TwitterError {
        try {
            String jsonBody = callTwitter(id)
            Tweet parsedTweet = parseBody(jsonBody)
            return parsedTweet
        } catch (Throwable t) {
            throw new TwitterError(t)
        }
    }

    private String callTwitter(String id) {
        // TODO: implementation
    }

    private Tweet parseBody(String jsonBody) {
        // TODO: implementation
    }
}

class Tweet {
    String id
    String userId
    String username
    String text
    Date createdAt
}

class TwitterError extends RuntimeException {}
 
TwitterController plays main part here. Users call show action along with id of a tweet. This action is my subject under test. I've implemented some basic functionality. It's easier to focus on it while writing tests.
 

class TwitterController {
    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet = twitterReaderService.readTweet(params.id)
        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}
 
Let's start writing a test from scratch. Most important thing here is that I use mock for my TwitterReaderService. I do not construct new TwitterReaderService(), because in this test I test only TwitterController. I am not interested in injected service. I know how this service is supposed to work and I am not interested in internals. So before every test I inject a twitterReaderServiceMock into controller:
 

import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }
}
 
Now it's time to think what scenarios I need to test. This line from TwitterReaderService is the most important:
 

Tweet readTweet(String id) throws TwitterError
 
You must think of this method like a black box right now. You know nothing of internals from controller's point of view. You're only interested what can be returned for you:
 
  • a TwitterError can be thrown
  • null can be returned
  • Tweet instance can be returned
This list is your test blueprint. Now answer a simple question for each element: "What do I want my controller to do in this situation?" and you have plan test:
 
  • show action should redirect to index if TwitterError is thrown and inform about error
  • show action should redirect to index and inform if tweet is not found
  • show action should show found tweet
That was easy and straightforward! And now is the best part: we use twitterReaderServiceMock to mock each of these three scenarios!
 
In Spock there is a good documentation about  interaction with mocks. You declare what methods are called, how many times, what parameters are given and what should be returned. Remember a black box? Mock is your black box with detailed instruction, e.g.: I expect you that if receive exactly one call to readTweet with parameter '1' then you should throw me a TwitterError. Rephrase this sentence out loud and look at this:
 

1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
 
This is a valid interaction definition on mock! It's that easy! Here is a complete test that fails for now:
 

import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }
}
 

| Failure:  show should redirect to index if TwitterError is thrown(pl.refaktor.twitter.TwitterControllerSpec)
|  pl.refaktor.twitter.TwitterError
 at pl.refaktor.twitter.TwitterControllerSpec.show should redirect to index if TwitterError is thrown_closure1(TwitterControllerSpec.groovy:29)
 
You may notice 0 * _._ notation. It says: I don't want any other mocks or any other methods called. Fail this test if something is called! It's a good practice to ensure that there are no more interactions than you want.
 
Ok, now I need to implement controller logic to handle TwitterError.
 

class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}
 
My tests passes! We have two scenarios left. Rule stays the same: TwitterReaderService returns something and we test against it. So this line is the heart of each test, change only returned values after >>:
 

1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
 
Here is a complete test for three scenarios and controller that passes it.
 

import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {

    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }

    def "show should inform about not found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> null
            0 * _._
            flash.message == 'Tweet not found'
            response.redirectUrl == '/twitter/index'
    }


    def "show should show found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> new Tweet()
            0 * _._
            flash.message == null
            response.status == 200
    }
}
 

class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}
 
The most important thing here is that we've tested controller-service interaction without logic implementation in service! That's why mock technique is so useful. It decouples your dependencies and let you focus on exactly one subject under test. Happy testing!