Simplified EJB Component Packaging

The EJB 3.0 Specification simplified many aspects of EJB component development. It reduced the number of required classes and interfaces, established intelligent defaults, and made the ejb-jar.xml file optional, to name just a few.

However, the specification still requires that all EJB components be packaged within an ejb-jar file. In many cases this restriction adds undue complexity to Java EE development. To remedy that, we're planning to allow EJB components to be packaged directly within a .war file, without the need for an ejb-jar.

Let's look at an example. Assume we have a simple Stateless Session Bean that exposes a no-interface view :

   1:  package com.acme;
   2:   
   3:  @Stateless
   4:  public class FooBean {
   5:    public void foo() { ... }
   6:  }

Normally, accessing this bean from a Servlet would require one .war, one ejb-jar, and an .ear file to wrap the two modules together. With the new packaging alternative, everything fits into a single .war :
$ jar tf foo.war 
WEB-INF/classes/com/acme/FooBean.class
WEB-INF/classes/com/acme/FooServlet.class
WEB-INF/web.xml

It's important to point out that the goal here is to remove an artificial packaging restriction, not to create a new flavor of EJB component that uses web container APIs. From an EJB component's perspective it still lives within the same managed runtime environment as before. This is important, as it keeps the programming model independent of packaging decisions.

Here are some more details about how the new packaging approach would likely be defined :

  • EJB component classes are packaged within WEB-INF/classes and/or in WEB-INF/lib.
  • EJB components share the same classloader as other classes in WEB-INF/classes and WEB-INF/lib.
  • EJB components share the .war's module-level component environment. For example, a resource-ref defined within web.xml would be visible to any EJB components in the .war.
  • EJB components have visibility to any persistence units defined within the .war.
  • ejb-jar.xml is optional. If needed, it is placed in WEB-INF/.
  • There are no special restrictions placed on a .war just because it contains EJB components. It can be deployed as a stand-alone .war or included within an .ear along with any number of other .wars or ejb-jars.
  • The full EJB feature set is available. For example, it would be possible to define a message-driven bean by placing a bean class annotated with @MessageDriven within WEB-INF/classes.

That's a quick overview of a new simplified alternative to EJB component packaging. Please post comments here or send them to our EJB 3.1 feedback alias.
Comments:

This is something that i have been waiting for a while now, it just makes so much sense and simplifies so many unnecessary issue that go with packaging a ejbs and wars independently even with the use of EAR file.cheers.

Posted by Jetender on May 12, 2009 at 08:27 PM EDT #

that's good.

Posted by jiaqiang on July 01, 2009 at 12:17 AM EDT #

学习中.....

Posted by 聚资库 on August 07, 2009 at 06:23 PM EDT #

support of louzhu,louzhu work hard

Posted by http://www.uggshelf.com/Products.html on October 14, 2009 at 04:22 PM EDT #

Ken Saks, you are Ed Milliband! (image search to see what I mean)

Posted by Ed on June 24, 2010 at 12:08 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Ken Saks is the Spec Lead for Enterprise JavaBeans (EJB) 3.1 and a Senior Staff Engineer in the Java Platform, Enterprise Edition team at SUN.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today