Skip navigation

I'm extremely excited about the coming weeks, because they will provide a unique opportunity to talk at two major events about several projects that I've been involved in, here at JBoss.


A few talks will be about Spring and Java EE. Now, one of the goals of projects such as Snowdrop is to make sure that JBoss, a Java EE certified runtime, is the best runtime for Spring applications. Other projects, such as Arquillian and Forge, while Java EE-focused at the core, include significant Spring support as well, for in-container testing and rapidly developing applications. The unifying thread of all these efforts is the fundamental belief we all share that combining the development model of Spring with the power of Java EE services is not only a viable, but a desirable approach when building Spring applications, and it is a key approach for Spring developers when looking forward to adopting the Java EE-development model, for example, CDI. So, if Spring and Java EE interest you, come hear about the JBoss perspective on it from me.


At Java One:


  • come at the JBoss mini-theater on Monday October 1st at 12:00pm, for a  "Spring on JBoss session"  focused specifically on the best practices of building Spring applications on JBoss AS. I'll show you how to use tools like Forge and Arquillian to get the best out of your Spring projects.
  • on Thursday, October 4, at 3:30pm, attend my session CON10659 - "Migrate from Spring to Java EE: Approaches and Techniques for Spring developers". I'll give you a pragmatic introduction to the tools that can help you understand and use efficiently Java EE, if you already have experience with Spring - learning how to use the infrastructure, how to do in-container testing and finally integrate Java EE components with Spring using a CDI bridge (and why would you want to do that). As Java EE 6 is becoming more popular, and we are gearing towards Java EE7, it will be an interesting walkthrough for you, especially if you have lived on the other side of the fence, so to speak.


At Spring One:

  • on Wednesday, October 17 at 4:30 pm, attend Juergen Hoeller's and my session about "Java EE Services for Spring Applications". We will talk about the more common and less-common used Java EE service, Java EE 6 and Java EE7, what should you expect from an application server in terms of services and how can you circumvent that (and what are the implications),what are the options for integrating Spring and Java EE native development models. It's quite a lot of topics, but it's all very interesting, and I'm excited by it, especially as, needless to say, it's an honour to co-present along Juergen.


See you there!

I am happy to announce the release of Snowdrop 2.0.2.Final. The main purpose of this release was to address compatibility issues with Spring 3.1, found in previous versions of Snowdrop.


The complete release notes can be found here. Please download the new release, and try it out!

I am happy to announce the release of Snowdrop 2.0.1. This new release fixes a few issues (to be found here), out of which the most important concerns compatibility with JBoss 7.1.Beta1 and later.


Try it out here, and let us know how it worked for you.

Cross-posting from


It took a while to release it (due to other work that needed to be completed first), and it took me a couple of weeks to announce it (i.e. until now), but my bit of news for today is this: the first release of our CDI Spring bridge, aka Seam Spring 3.1.0.Alpha1 is out.


The details are on the module main page, and an explanation on how it works is on the documentation page.


This first release provides:


  • facilities to bootstrap Spring contexts or access outstanding Spring contexts (e.g. web contexts bootstrapped by the ContextLoaderListener)
  • facilities to import Spring beans as CDI beans (thus making them available for standard CDI injection)
  • facilities to import CDI beans an Spring beans (thus making them available for Spring injection), including dedicated namespace support


As this is an Alpha, I am looking forward for feedback, new feature suggestions (even suggestions on prioritizing certain items that we have on the roadmap). Please use it extensively, and file bug reports(they're inevitable, and the sooner, the better).


Usage examples can be found for now in the Arquillian tests of the project source code, and I will follow up with a post describing a detailed example pretty soon.

Snowdrop 2.0.0.Final is released - the announcement is here:

JBoss AS7 has been released today, and there are definitely more than 7 reasons to love it.  By now, you have probably learned about its new features and have viewed the webinars. If not, I strongly recommend you to do so.


I'd like to follow up with a few practical examples of running Spring applications in JBoss AS7. And if you are interested in a deeper dive into the topic, continue following my blog, as this is my first post in a series that will cover:

  • an in-depth overview of dependency management and classloading and its implications for Spring;
  • persistence configuration options;
  • migrating Spring applications from older versions of JBoss AS;
  • integrating with enterprise services such as messaging and caching (including distributed and replicated caches);
  • the upcoming Snowdrop 2.0 release

... and many more. All focused on Spring and JBoss AS7.


There's a "Hello World" for every new technology. For this blog, the "Hello World" is actually a group of Spring examples, from the official example repository:

  1. Spring MVC showcase
  2. Webflow-primefaces-showcase
  3. Spring Petclinic
  4. Spring Travel


I will walk through the steps of building and deploying these applications, indicating what changes need to be made in order to get the respective application working.


You can also find the complete modified examples in my GitHub copy of the original Spring examples svn repository:


Deploying and running the examples


Each example is a Maven-based project. Therefore a simple:


mvn clean package


will build you the appropriate war file in each case.


Then, you can deploy them in JBoss AS as follows:


cp target/<war-name>.war $JBOSS_HOME/standalone/deployments

Changes required

So, did I need to make any changes in order to get these examples run in JBoss? To begin answering that question - the changes weren't so many. In older versions of JBoss AS, the first step would have been a general pruning of the server-provided dependencies from each application, but due to the modular classloading strategy, there aren't so many server-provided dependencies that make server classes visible to your deployment. Therefore, the chance of a conflict is greatly reduced.

Spring MVC showcase

I chose it because it is an application that demonstrates most of the Spring 3 MVC features. It needs no changes in order to build and deploy properly in JBoss.  Building and copying the war in the right place is all what you need to do.

Webflow Primefaces Showcase

I chose it because it is a Spring Webflow application, and also an example of Spring JSF integration. Again, no changes. Running in JBoss AS7 comes down to building and deploying the war.

Spring Petclinic

The previous examples were mostly demos for Spring's presentation layer capabilities. How about throwing some persistence into the mix? Petclinic is a good testing ground for that, because it provides not one, but 3 persistence strategies (or 5, if you count the different persistence providers separately):

  • native JDBC;
  • native Hibernate;
  • JPA (with an option to use EclipseLink, OpenJPA and Hibernate as persistence providers).

You can switch between the options by changing the web.xml file, as well as the jpa-persistence.xml file (for switching between the various providers).

Some cleanup

One first change that I had to do to Spring Petclinic was to update Spring from 3.0.0 to 3.0.5. Apart from the fact that latest is always best, this was necessary in order to avoid running into, which causes Spring 3 versions earlier than 3.0.3 not to work properly on JBoss AS6 and JBoss AS7.


Also, the Spring MVC bean definitions needed to change a bit, because the servlet mapping to '/*' was not compatible with JBoss AS7 - neither does it work on versions of Tomcat 6.0.32+ or Tomcat 7. This is also reported as

Both fixes are shown here.


Finally, there is bug in the application which does not prevent the application from deploying and running, but will cause it to crash when trying to delete a pet (it's not an integration issue, but simply an application bug). The fix is here.


What we have gotten so far is an application which uses Spring 3.0.5 and can run on latest versions of Tomcat.

Spring Petclinic with Native JDBC

The application runs without further changes.

Spring Petclinic with Native Hibernate

The application runs without further changes if the class EntityManagerClinic, which is not employed by the application is excluded from the build [1]. It's worth spending a bit time on this, though.


Spring 3.0 (and likely 3.1 as well) is not compatible with Hibernate 4, which is the version used by the application server. However, the Petclinic application packages Hibernate 3 already, and due to the modular classloading features of JBoss AS7, the Hibernate module (or Hibernate libraries) are not added to deployment's classpath. If you wanted, you could have added them explicitly, but in this case it's not advisable: the application runs with the included libraries).

Spring Petclinic with JPA (Hibernate)

For this example, we will switch the persistence provider to Hibernate. Eclipse and OpenJPA require the presence of a LoadTimeWeaver, and the one provided by Spring 3.0 is not compatible with JBoss AS7. While this may be supported by a fix in Spring 3.1/3.2, Snowdrop 2.0 will contain a JBoss AS7-compatible LoadTimeWeaver. However, I prefer to address the topic of load-time weaving in a dedicated post. Also, Hibernate is the most popular JPA provider when running on JBoss and does not require a load-time weaver, so this choice this will already cover a majority of the use cases.


In order to switch to Hibernate, change the applicationContext-jpa.xml file and switch the jpaVendorAdaptor to org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter as shown here. Your final definition should look like this:


<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
     <property name="jpaVendorAdapter">

        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"
              p:database="${jpa.database}" p:showSql="${jpa.showSql}"/>
     <property name="persistenceXmlLocation" value="classpath:META-INF/jpa-persistence.xml"/>


In the previous case, the application was isolated from the Hibernate libraries. But for applications that use JPA, the persistence API and Hibernate libraries are attached automatically by the server, as described here.


So it is necessary to tell JBoss not to include these. You can do this very easily, by adding a /WEB-INF/jboss-deployment-structure.xml file with the following content:


<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
       <module name="org.hibernate"/>



After doing so (the commit is here), the application is good to go.


Spring Travel

Spring Travel uses Spring Webflow, and it is another example of Spring JPA integration. In a similar fashion to Spring Petclinic JPA, it uses a Spring-bootstrapped EntityManagerFactory.


The main difference between Spring Petclinic and Spring Travel is that, while Spring Petclinic describes its persistent unit in a WEB-INF/classes/META-INF/jpa-persistence.xml file, Spring Travel uses /WEB-INF/classes/META-INF/persistence.xml as its persistence unit configuration location.


Since the content of /WEB-INF/classes/META-INF/persistence.xml  is not a deployable persistence unit definition (e.g. there is no datasource definition, which is supposed to be supplemented by Spring), the application will not deploy properly. In order to prevent that from happening, you may rename the persistence unit definition file and update the entity manager factory bean definition as in the following commit. Here is how your Spring definition may look like:



<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
   <property name="dataSource" ref="dataSource" />
   <property name="jpaVendorAdapter">
        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
   <property name="persistenceXmlLocation" value="classpath*:META-INF/jpa-persistence.xml"/>



In future versions of JBoss AS it will be possible to instruct the application server to suppress the deployment of a persistence units altogether which would elliminate the need to rename the file. Until then, renaming the persistence definition file is a Spring-supported way of ensuring that no conflicts exist. And it is portable across application servers!


As well, because Spring 3 cannot interact properly with the Hibernate 4 module added automatically by the server, you need to exclude the 'org.hibernate' module by adding the /WEB-INF/jboss-deployment-structure.xml as shown above. Here's the commit.


Note that starting with Spring 3.1.0.RC1 (unreleased at the time when this article was written), it will be possible to use Hibernate 4 as a JPA provider with Spring (but not in a native scenario), so you may opt between including Hibernate in your application and excluding the server-provided module or using the server dependency (case in which we advise to exclude Hibernate from your build). [See note 2]


After doing so, you can build, run the example and enjoy the power of the JBoss AS7.


My main goal was to show you how a few Spring examples which have not been specifically designed to be compatible with JBoss AS7 can be deployed and executed without changes, or in the worst case scenario, with a minimal set of changes.


The new modular classloading strategy of the application server reduces the number of conflicts and duplications, and allows you more leeway to package your own dependencies in the application. The only time when a conflict happened was for JPA applications and you have seen how to elliminate the classloading conflicts, as well as how to prevent the server from acting upon a file which is not compatible with the Java EE deployment requirements.


There is many more to discuss about persistence management in JBoss AS7. In my next post, I will dive a bit deeper into the persistence configuration options and how do they affect Spring applications. 




[1] The EntityManagerClinic is not being used in the Hibernate version of the application. However, the presence of the @PersistenceContext       annotation will lead to the addition of the Hibernate 4 module as a dependency as shown here. If you would prefer to include this class in the deployment, then add the /WEB-INF/jboss-deployment-structure.xml to the project as well.


[2] Thanks to Juergen Hoeller for providing this information.




1. Corrected file name from /WEB-INF/jboss-deployment-structure.xml

2. Added information about Hibernate 4 JPA support in Spring 3.1.0.RC1

3. Clarified the behaviour of the Hibernate version of the application, mentioning the exclusion of EntityManagerClinic.