From Spring to Java EE 6

Bernard LignyNovember 27th, 2011Last Updated: October 22nd, 2012

5 196 9 minutes read

I recently worked on a quite complex project mixing many Java EE 6 technologies (such as JPA, JAXB, JMS, JTA, JAX-RS, etc…). For productivity and planning reasons, the prototyped application was designed as a standalone pure Spring application. When the development of the real application started, we re-challenged our initial choice (i.e. Spring v3) and analyzed the interest of switching to a Java EE 6 app server like GlassFish or JBoss.
This finally ended up in two major questions:

can we do in Java EE 6 everything we can do in Spring ?
can we do that as easy as in Spring ?

Well, I would say that, globally, the answer is: yes we can !

I do not want to reopen the (endless) debate of knowing which one, between Spring and Java EE 6, is the best. No, I just want to share with you my experience regarding this migration. I was – and I am still – a real Spring fanboy (which I, historically speaking, discovered after having been literally disgusted by EJB’s 1.0), but I am also aware of the recent progress, not to say simplifications, that have been introduced in Java EE these last years, as well as the impressive speed improvements on the side of Java EE 6 application servers.

Let us now study in details some typical requirements of “enterprise” applications, and compare the code to produce in both worlds for:

Contexts & Dependency Injection
Messaging
Transaction management
Web services

This comparison should provide you with some concrete decision elements in the event you hesitate to migrate from one technology to the other…

Part I : Contexts & Dependency Injection (CDI)

Spring allows you to define beans using various stereotypes (eg @Repository, @Service, @Controller, and @Component). The one to choose is not that important (that’s not entirely true. For instance, tagging your DAO as @Repository will add the automatic translation of SQL exceptions) as this distinction is mostly intended to IDE’s (in order to categorize beans). Optionally, you can give your bean an alias.

public interface MyInterface {...}

import org.springframework.stereotype.Component;

@Component("firstBean")
public class MySpringBean implements MyInterface {...}

@Component("firstBeanMock")
public class MockImpl implements MyInterface {...}

Java EE provides a very similar annotation (@Named) but its use should be limited to pure pojo’s. In case of service-oriented beans (especially transactional coarse-grained services), consider using a (preferably stateless) EJB – namely because they offer better scalability.

import javax.inject.Named;

@Named("firstBean")
public class MyJeeBean implements MyInterface {...}

import javax.ejb.Stateless;

@Stateless(name="firstService")
public class MyJeeService implements MyInterface {...}

Also beware that, in contrary to Spring, singletons should be explicitly marked as such in Java EE:

import javax.inject.Singleton;

@Singleton
public class MyJeeSingleton implements MyInterface {...}

Remark: you may get confused when choosing between a “javax.inject.Singleton” and a “javax.ejb.Singleton”. The first one defines a standard POJO managed by the container (aka a “Managed Bean” in the Java EE world), while the second one defines an “Enterprise Bean”. Remember that the later is designed for concurrent access (a client doesn’t need to worry about any other clients that may be simultaneously invoking the same methods of the singleton) and also offers transaction management facilities (see further).

Now that we have registered (and optionally named) our beans, we can inject them in other beans. Once again, the procedure is somewhat similar at both sides:

SPRING

import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;

@Component
public class UseCaseHandler {

  @Autowired
  @Qualifier("firstBean")
  private MyInterface serviceFacade;
  
}

JAVA EE 6

import javax.inject.Named;
import javax.inject.Inject;

@Named
public class UseCaseHandler {

  @Inject
  @Named("firstBean")  
  private MyInterface serviceFacade;
  
}

Remark: The JSR-330 has unified the way to inject managed beans. This concretely means that the @Inject annotation can be used to inject simple POJOs as well as EJB’s (making thereby the @EJB annotation a bit obsolete).

Fine ! However, in the real world, the name (eg “firstBean”) of the beans we want to inject might be dynamic. This is particularly true as soon as you play with behavioral patterns, generics, etc…

In Spring, this is pretty easy. You can for instance make your bean ApplicationContext-aware, so that you can then use the injected Spring context in order to lookup for specific bean instances:

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Service;

import com.javacodegeeks.Request;

@Service
public class Dispatcher implements ApplicationContextAware {
 
 private ApplicationContext appContext;

 public void setApplicationContext(ApplicationContext ctx) throws BeansException {
  appContext = ctx;
 }
 
 public void dispatch(Request request) throws Exception {
  String beanName = "requestHandler_" + request.getRequestTypeId();
  RequestHandler myHandler = appContext.getBean(beanName, RequestHandler.class);
  myHandler.handleRequest(request);
 }
 
}

public interface RequestHandler  {
 public void handleRequest(Request request);
}

@Component("requestHandler_typeA")
public class HandlerA implements RequestHandler {...}

@Component("requestHandler_typeB")
public class HandlerB implements RequestHandler {...}

In Java EE 6, the same is possible but yet requires a bit more lines of code (that could be centralized in an helper class):

import java.util.Set;
import javax.inject.Inject;
import javax.inject.Named;
import javax.enterprise.context.spi.CreationalContext;
import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;

import com.javacodegeeks.Request;

@Named
public class Dispatcher 
 
 @Inject
 private BeanManager beanManager;
 
 public void dispatch(Request request) throws Exception {
  String beanName = "requestHandler_" + request.getRequestTypeId();
  RequestHandler myHandler = this.getBean(beanName, RequestHandler.class);
  myHandler.handleRequest(request);
 }
 
 @SuppressWarnings("unchecked")
 private <T> T getBean(String name, Class<T> clazz) throws Exception {
  Set<Bean<?>> founds = beanManager.getBeans(name);
  if ( founds.size()==0 ) {
   throw new Exception("No such bean found: "+name);
  } else {
   Bean<T> bean = (Bean<T>) founds.iterator().next();
   CreationalContext<T> cc = beanManager.createCreationalContext(bean);
          T instance = (T) beanManager.getReference(bean, clazz, cc);
          return instance;
  }
 }
 
}

public interface RequestHandler  {
 public void handleRequest(Request request);
}

@Named("requestHandler_typeA")
public class HandlerA implements UseCaseHandler {…}

@Named("requestHandler_typeB")
public class HandlerB implements UseCaseHandler {...}

PART II : JMS

Java Messaging Service eases the implementation of a loosely coupled distributed communication.
This is why it has become a classical technique in Enterprise Application Integration (EAI).

Spring has an outstanding JMS support. You can very quickly setup JMS producers or consumers,
with destination resolvers, and optionally with an automatic conversion of JMS messages into pojos (and vice-versa). On the other hand, J2EE comes with a rich set of annotations in order to access or define JMS resources such as queue/topics, connection or messages-oriented beans.

Let’s start with a JMS client that receives messages, that is a message consumer (or subscriber):

SPRING

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
 <property name="environment">
         <props>…</props>
 </property>
</bean>
    
<bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiTemplate" ref="jndiTemplate" />
      <property name="jndiName" value="java:/JmsXA" />
</bean>
    
<bean id="jndiDestResolver"
 class="org.springframework.jms.support.destination.JndiDestinationResolver">
 <property name="jndiTemplate" ref="jndiTemplate" />
</bean>
 
<bean id="jmsContainer"
 class="org.springframework.jms.listener.DefaultMessageListenerContainer">
 <property name="connectionFactory" ref="jmsConnectionFactory"/>   
 <property name="destinationResolver" ref="jndiDestResolver"/>  
 <property name="destinationName" value="queue/myQueue"/>
 <property name="messageListener" ref="myMsgConsumer" />
</bean>
   
<bean id="myMsgConverter" class="com.javacodegeeks.MsgToRequestConverter"/>
   
<bean id="myMsgConsumer" class="com.javacodegeeks.MsgConsumer"/>

import javax.jms.Message;
import javax.jms.MessageListener;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jms.support.converter.MessageConverter;

import com.javacodegeeks.Request;
import com.javacodegeeks.Dispatcher;
        
/**
 * Example of message consumer (Message-Driven-Pojo) in Spring
 */
public class MsgConsumer implements MessageListener {
 
    @Autowired
    private MessageConverter msgConverter;
 
    @Autowired
    private Dispatcher dispatcher;
     
    public void onMessage(Message message) {       
     try { 
      Request request = (Request) msgConverter.fromMessage(message);
      dispatcher.dispatch(request); 
     } catch (Exception e) {
    e.printStackTrace();    
     } 
    }

}

JAVA EE 6

import javax.inject.Inject;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.ejb.MessageDriven;
import javax.ejb.ActivationConfigProperty;

import com.javacodegeeks.Request;
import com.javacodegeeks.Dispatcher ;
import com.javacodegeeks.MsgToRequestConverter;

/**
 * Example of message consumer (Message-Driven-Bean) in JEE
 */
@MessageDriven(activationConfig = { 
 @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue="queue/myQueue") 
} )     
public class MsgConsumer implements MessageListener  {
 
 @Inject
     private MsgToRequestConverter msgConverter;

 @Inject 
 private Dispatcher dispatcher;
 
 public void onMessage(Message message) {       
     try { 
      Request request = msgConverter.fromMessage(message);
      dispatcher.dispatch(request);      
     } catch (Exception e) {
  e.printStackTrace();     
 } 
    }
    
}

Let’s now code a JMS client that creates and sends messages, that is a message producer (or publisher):

SPRING

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
 <property name="environment">
    <props>…</props>
 </property>
</bean>
    
<bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiTemplate" ref="jndiTemplate" />
      <property name="jndiName" value="java:/JmsXA" />
</bean>
    
<bean id="jndiDestResolver"
 class="org.springframework.jms.support.destination.JndiDestinationResolver">
 <property name="jndiTemplate" ref="jndiTemplate" />
</bean>

<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
 <property name="connectionFactory" ref="jmsConnectionFactory" />
 <property name="destinationResolver" ref="jndiDestResolver" />
 <property name="messageConverter" ref="myMsgConverter" />
</bean>
    
<bean id="myMsgConverter" class="com.javacodegeeks.MsgConverter">

import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jms.core.JmsTemplate;
import com.javacodegeeks.Request;

/**
 * Example of message producer component in Spring
 */
@Component 
public class MsgProducer {

 @Autowired
 private JmsTemplate jmsTemplate;
 
 public void postRequest(Request request) throws Exception {
  jmsTemplate.convertAndSend("queue/myQueue", request);
 }
 
}

JAVA EE 6

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.inject.Inject;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.ejb.Stateless;
import javax.ejb.EJBException;

import com.javacodegeeks.Request;
import com.javacodegeeks.MsgToRequestConverter;

/**
 * Example of message producer (here a session bean) in JEE
 */
@Stateless(name="msgProducer")
public class MsgProducer {
 
 @Inject
     private MsgToRequestConverter msgConverter;

 @Resource(mappedName="java:/JmsXA")
 private ConnectionFactory connectionFactory;
 
 @Resource(mappedName="queue/myQueue")
 private Queue queue;
 
 private Connection jmsConnection;


 @PostConstruct
 private void initialize() {
  try {
   jmsConnection = connectionFactory.createConnection();
  } catch (JMSException e) {
   throw new EJBException(e);
  }
 }
 
 
 @PreDestroy
 private void cleanup() {
  try {
   if (jmsConnection!=null) jmsConnection.close();
  } catch (JMSException e) {
   throw new EJBException(e);
  }
 }
 
 
 public void postRequest(Request request) throws Exception { 
  Session session = null;
  MessageProducer producer = null;
  try {
   session = jmsConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
   producer = session.createProducer(queue);
   Message msg = msgConverter.toMessage(request, session);
       producer.send(msg);  
  } finally { 
   try { 
    if (producer!=null) producer.close();
    if (session!=null) session.close();
   } catch (Exception e) {
    System.err.println("JMS session not properly closed: "+ e);
   }
  }
 }
 
}

Remarks:

Do not forget that, in contrary to JMS connections and JMS queues, JMS sessions are not thread-safe. Sessions should therefore not be shared by all bean instances, nor be created in the constructor or in a PostConstruct method.
PostConstruct and PreDestroy methods should only throw runtime exceptions; this is the reason why JMS exceptions have to be wrapped (for instance) into EJB exceptions.

Part III : Transaction management

The need for transactions is crucial in system architecture, especially with the advent of SOA. In such architectures, coarse-grained transactional services can be built by assembling existing – possibly also transactional – smaller services (“microservices”).

Both Spring and Java EE fulfills this need by offering a powerful declarative (annotation-based) transaction management.

SPRING

<!-- Recognize @Transactional annotations in our beans --> 
<tx:annotation-driven transaction-manager="txManager"/>

<!-- The transaction manager to use (here the JPA implementation) --> 
<bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
 ...
</bean>

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.annotation.Propagation;

import com.javacodegeeks.Request;
import com.javacodegeeks.RequestProcessor;

@Service
public class RequestProcessorImpl implements RequestProcessor {

 @Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
 public void process(Request request) throws Exception {
  ...
 }
 
}

JAVA EE 6

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

import com.javacodegeeks.Request;
import com.javacodegeeks.RequestProcessor;

@Stateless
@TransactionManagement(value=TransactionManagementType.CONTAINER)
public class RequestProcessorImpl implements RequestProcessor {

 @TransactionAttribute(TransactionAttributeType.REQUIRED)
 public void process(Request request) throws Exception {
  ...
 }
 
}

Be very careful with runtime/unchecked exceptions in Java EE. By default, they are automatically wrapped by the EJB container into an EJBException, which may cause surprising results (especially in try…catch statements!). If you need finer tuning of rollback cases, consider tagging such runtime exceptions as applicative exceptions, either using the @ApplicationException annotation, or by augmenting the ejb descriptor like this:

<ejb-jar>
   <assembly-descriptor>
    <application-exception>
      <exception-class>java.lang.NullPointerException</exception-class>
      <rollback>true</rollback>
    </application-exception>
   </assembly-descriptor>
</ejb-jar>

Part IV : Restful web services

Enterprise applications often need to expose some of their services to the outside world, typically through internet. This is where web services are coming into play. Like JMS (for asynchronous communication), web services are another classical integration technique for implementing a synchronous, request-response oriented, communication using XML (or JSON) as exchange format.

SPRING

<servlet>
 <servlet-name>ws</servlet-name>
 <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
 <servlet-name>ws</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>

<!-- Dispatch requests to controllers + use JAXB (if found in the classpath) -->
<mvc:annotation-driven />

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;

import com.javacodegeeks.Geek;
import com.javacodegeeks.GeekService;

@Controller
@RequestMapping("/geeks")
public class GeekWebService {
 
   @Autowired
   GeekService bizService;
   
  @RequestMapping(value="/{id}", method=RequestMethod.GET)
  @ResponseBody
  public Geek getGeek(@PathVariable("id") long geekId) {
     return bizService.findGeek(geekId);
 }
 
}

import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement(name="geek")
public class Geek {
 
 private String name;
 private Long id;
 
 @XmlElement
 public String getName() {
  return name;
 }
 
 public void setName(String name) {
  this.name = name;
 }
 
 @XmlAttribute
 public Long getId() {
  return id;
 }
 
 public void setId(Long id) {
  this.id = id;
 }
 
}

JAVA EE 6

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import com.javacodegeeks.Geek;
import com.javacodegeeks.GeekService;

@Path("/geeks")
@Produces(MediaType.APPLICATION_XML)
public class GeekWebService {

 @Inject
  GeekService bizService;
   
 @GET
 @Path("/{id}")
 public Geek getGeek(@PathParam("id") long geekId) {
    return bizService.findGeek(geekId);
  }
  
}

import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement(name="geek")
public class Geek {
 
 private String name;
 private Long id;
 
 @XmlElement
 public String getName() {
  return name;
 }
 
 public void setName(String name) {
  this.name = name;
 }
 
 @XmlAttribute
 public Long getId() {
  return id;
 }
 
 public void setId(Long id) {
  this.id = id;
 }
 
}

Remark: some JAX-RS implementations, like JBoss RestEasy, do not require to modify the web.xml in order to configure and install web services…

PART V : Conclusion

Arguing that things are in Spring much simpler, much lighter than in Java EE is not – more exactly, no more – true. It is merely a matter of taste. Furthermore, recent Java EE 6 application servers (like GlassFish 3 or JBoss 6 & 7) are booting really fast, actually nearly as fast as Spring applications. Nevertheless, in a “best-of-breed” perspective, it may still be interesting to combine both technologies; this will be the subject of my next post on JCG :-)

Reference: From Spring to Java EE 6 from our W4G partner Bernard Ligny.

Related Articles :