Are Plain Old WebContainers still appropriate in Java EE 5?

J2EE 1.4 and especially EJB 2.X were not very lean and efficient to develop. The escape to POJOs and WebContainer only approach was often the resulting conclusion and way to go for many "enterprise" projects.
Some projects built even own infrastructure, just to avoid the usage of EJB 2.0. However the development and runtime environment changed very much. Java EE 5 with EJB 3.0 simplified drastically the development and especially deployment model. No huge deployment descriptors are needed (actually no XML at all) - to develop a session bean just a class and an interface are needed. Actually it is hard to simplify the EJB 3.0 (suggestions are really welcome).
The funny story is: Java EE 5 webapplications without EJB 3 Session Beans are more complicated. I copied the following example from the blueprints to show the additional code which is needed:

@PersistenceContext(name="foo", unitName="myPuName")
public class MyServlet extends HttpServlet {

@Resource UserTransaction utx;

  public void doGet(HttpServletRequest req,
                    HttpServletResponse resp) throws throws ServletException, IOException {

    EntityManager em = (EntityManager) ic.lookup("java:comp/env/foo");

    //get data from request
    String name = request.getParameter("item_name");
    //create new Item entity
    Item item = new Item();
    //set values of Item entity
    em.persist(item); //persist and add new Item to database
Of course no one would use the EntityManager directly in the Servlet, but rather in e.g. Struts Action or JSF managed bean. But also in that cases you have to care about the lookup, thread-safety and transaction management.

An introduction of simple Session Bean could drastically simplify the situation. In that particular case the container would care about the managment of the EntityManager, concurrency as well as transactions.

The servlet code would like something like:

public class MyServlet extends HttpServlet {

@EJB ItemMgr mgr;

public void doGet(HttpServletRequest req,
                    HttpServletResponse resp) throws throws ServletException, IOException {
mgr.addItem("name of item");

The bean code is simple as well:

public class ItemMgrBean{

@PersistenceContext EntityManager em;

public void addItem(String name){
    Item item = new Item();

The code not only simpler but also cleaner. The resources are managed and injected by the container. But with the introduction of a single Session Bean the manageability and monitoring can be significantly increased. With tools like Glassfish's call flow you can monitor the performance of the whole invocation stack. The coolest story  - the XML-configuration is optional. In EJB 3.1 even the local interfaces will be optional. After this step there is no more room for simplifications :-).

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

Stay in touch:


Interesting topic, given that in EJB 3.1 it will also no longer be necessary to package your EJB's separately from your web application... From the JSR: "Support for direct use of EJBs in the servlet container, including simplified packaging options."

Not exactly sure what that will look like, but it sounds like EJB classes will be able to be deployed directly in a .war file... further simplification!


Posted by Matt Corey on August 21, 2007 at 04:13 PM CEST #


your are absolutely right. You will be able to package EJBs together with servlets - it really interesting,

thank you for your comment,

Posted by Adam Bien on August 21, 2007 at 09:28 PM CEST #

You're comparing this to the wrong thing... It's not "why would I use JEE 5 without EJB3?" it's "why would I use Spring instead of JEE 5?"

The thing is, as much nicer as EJB3 is vs. EJB 2.1, Spring is that much nicer than EJB3. EJB3 dependency injection is pretty weak compared to the full power that Spring gives you to wire your stack together. For example, how do you get a bean injected into your EJB3 SLSB if it's a class that's from a 3rd party library and it is not an EJB? EJB3 doesn't provide for POJO injection, only EJBs and resources can be injected.

Plus, why do I want to depend on different app servers implementing the EJB3 spec compatibly when I could just bring the Spring jars with me and always have a consistent implementation? If I decide to stick with a particular implementation of Spring, I can bring that with me to any app server or servlet container, and, if the specs move on and change, I won't have to upgrade or change my code if I don't want to. Will the newest release of your app server still run your EJB3 application in 5 years? 10? Maybe, maybe not.

If all you depend on the server for is basic services like Servlets, JMX, and JTA, you're in a much better position to be portable across containers and across time. Hell, if you need to, you can bundle in JMX and JTA providers into your app and wire them up with Spring, and just depend on Servlets. Servlet container differences (from the code point of view) are almost entirely non-existent and any small issues are handled by web app frameworks.

Posted by Jason Carreira on August 22, 2007 at 02:13 AM CEST #

I wonder how the <a href="">WebBeans JSR</a> for Java EE 6 will change things. It is based on Seam components with POJO bijection (injection and outjection). It can inject POJOs into EJBs, EJBs into POJOs, etc. Well, at least the component model in Seam that this JSR is based on can do that. WebBeans will not depend on JSF.

Posted by Ryan de Laplante on August 22, 2007 at 07:35 AM CEST #

Hi Jason,

sorry, but it actually wasn't my intention to compare Spring with EJB 3. I just observed in some projects, that people do not like EJB 3 and care themself about the management of resources - which is a bad thing.
However Interface21 (and so indirectly Spring) joined the Java EE 6 spec. So you can consider this post to be somehow Spring related :-).

Btw. Java EE 5, EJB 3 are VERY portable. Until I can move my apps between Glassfish v2, JBoss 4/5 and WLS 10 with a very small change in the persistence.xml.

thanks !

Posted by Adam Bien on August 22, 2007 at 11:20 AM CEST #

"For example, how do you get a bean injected into your EJB3 SLSB if it's a class that's from a 3rd party library and it is not an EJB? EJB3 doesn't provide for POJO injection, only EJBs and resources can be injected."

You can write an ejb-jar.xml file for your third-party class and get it wired by the container. Did you actually look at it?

Posted by on August 23, 2007 at 03:14 PM CEST #

When we started our first JEE 5 project, we found out very soon that the Servlets Specs and Engines had not evolved at the same pace of the EJB3.0, so using JPA inside the Web container with Spring sounded the best option. We developed a framework for projects with and without EJB3 Session Beans, but with JPA. EJBs are easier to manage and monitor as you have said and fits better in middleware architectures where the Web layer is not the only presentation layer, the profile of our customers.

We use Spring to reuse the PARs and the business logic between both options. We discovered that was easier to use JPA inside the Session EJBs than using the JPA inside the Web Container + Spring. I know this is not politically correct in this days of Spring dominance, but it's our experience.

Posted by Diego Parrilla on September 05, 2007 at 08:49 PM CEST #

I think there is still plenty of room for webcontainers only. JEE5 will not kill that, at all.

I agree with Jason C., in that it is a question of how much you would like to bind yourself to, in deployment. Just as you can say that using POJOs is a lightweight architecture, you can also say, that using webcontainer only in deployment, is a lightweight deployment model.

There are more webcontainers available. They are smaller/less complex/easier to manage. More good, free ones, available.

Posted by Tech Per on March 19, 2008 at 02:39 PM CET #

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