Migration To Java EE 6 With Spring 3 - ...Could Become "Interesting"

Spring 3 comes with JSR-330 annotations like @Inject, @Named developed by Rod Johnson and Bob Lee. Exactly the same annotations are also used in CDI (JSR-299). They are an integral part of every Java EE 6 server - regardless whether it is a full or web profile. In all migration projects from J2EE / Java EE 5 with Spring 3 to Java EE 6 you will get two injection frameworks implementing / listening to the same annotations.

It is like working with two JPA providers (e.g. EclipseLink and Hibernate) in one application at the same time :-).

Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition

airhacks.fm the podcast:

Stay in touch: airhacks.news.


I don't get it - how is that different from the support for e.g. JSR250 @Resource and JSR220 @TransactionAttribute that is in Spring for quite while?

Posted by Eberhard Wolff on June 29, 2011 at 10:15 PM CEST #

I think @Resource doesn't work with POJOs as per JEE5 specs?

Posted by faisal on June 29, 2011 at 11:11 PM CEST #


not that different. Which framework do you expect to react to @Inject?

If you inject a "POJO" with @Inject in Java EE 6, then @PostConstruct will be invoked by the application server.

If you are going to use Spring in Java EE 6, then you will get two frameworks "listening" to the same annotation. You will at least have to decide which classes are going to be injected by Spring and which by CDI....

Posted by Adam Bien on June 30, 2011 at 12:53 AM CEST #

Do you have a prototype that shows that really both frameworks are trying to "listening" to the annotation?

Posted by Eberhard Wolff on June 30, 2011 at 05:48 PM CEST #


no - I only have @Inject samples for Java EE 6. I could send you the maven-app. If you activate Spring 3 and declare the dependent class as Spring Bean, we will get an example :-). Should I drop you an email?

If there is beans.xml in classpath Java EE 6 will search for @Inject regardless whether Spring already uses them for injection, or not.

The only workaround would be to delete the beans.xml. Then only Spring would "react" to @Inject. It would look like a Java EE 6 injection.

IMHO: the easiest possible thing is to keep both frameworks separated.


Posted by Adam Bien on June 30, 2011 at 11:14 PM CEST #

I don't think this will be a problem Adam.

Both runtimes and their managed objects are strictly separated (ApplicationContext vs BeanManager) unless you use an bidirectional spring<->cdi integration. In this case you need to handle the issue within your CDI extension. Should be manageable while moving to one stack (either CDI or Spring).

Posted by Jens Schumann on July 01, 2011 at 02:32 AM CEST #


it is not a technical problem. It is a maintenance nightmare. You will need a clear policy + documentation which objects get injected by Spring and which by Java EE 6. It is impossible to tell without looking to configuration, checking the existence of beans.xml etc.

...very similar to using Hibernate and EclipseLink through JPA in one project. If you clearly separate the entities - should be also possible :-)

thanks for your comment!,


Posted by Adam Bien on July 01, 2011 at 02:45 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments