EJB 3.1 Early Draft Now Available

I'm happy to announce that the Enterprise JavaBeansTM (EJB) 3.1 Early Draft is now available.

The Expert Group has been working hard since we launched JSR 318 last August and we're looking forward to your feedback. Please send comments to jsr-318-comments@jcp.org

The EJB 3.1 Specification has two main goals. The first is a continued focus on ease-of-use. The EJB 3.0 Specification made a huge improvement in this area with the introduction of the EJB Simplified API but we can do much more. The second goal is to add many of the new features that have been requested from the community for some time.

Here is a brief overview of the topics being considered. I'll be following up with more detailed posts on each topic. Just a reminder that we're still relatively early in the process so the exact feature set is subject to change.

.war packaging of EJB components
The EJB 3.0 Specification made it simpler to develop EJB components by reducing the number of necessary classes and .xml files. However, EJB components are still required to be packaged within their own ejb-jar file, which complicates the development of applications that make use of both web and EJB functionality. This enhancement will allow EJB components to be packaged and deployed directly within a .war file, without an ejb-jar.

Optional Local Business Interfaces
Although the EJB 3.0 Local view has proven to be a significant improvement over its predecessor, there are cases where developers would prefer to avoid using a separate interface altogether. Making the local business interface optional will allow a bean developer to implement a component using only a bean class.

EJB "Lite"
The Java EE 6 Specification will be introducing Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. EJB "Lite" defines a small portion of the EJB 3.1 API for use in these subset EE profiles. This will give vendors the flexibility to provide EJB support across a wide variety of EE profiles.

Portable EJB Global JNDI Names
One common source of frustration for developers is the non-portability of the mapping information (e.g. global JNDI names) used to resolve and lookup EJB references. We'll investigate ways to standardize this information so that applications can be deployed without the need for vendor-specific EJB component mappings.

A common problem encountered by developers is how to portably share state between the EJB components in an application. In contrast, the web container has always provided this capability via properties on the ServletContext. A new Singleton bean type will allow for easy sharing of state within the entire application.

Application Initialization and Shutdown Events
EJB applications often need to perform tasks at the point that the application is initializing and/or shutting down. These lifecycle callbacks are supported in the web tier but have never been available directly within the EJB component model.

EJB Timer Service Enhancements
The two most commonly requested new EJB Timer Service features are calendar-based timer expressions and the ability to have an EJB timer created automatically as a result of deployment.

Simple Asynchrony
The main option available to EJB developers who are interested in adding asynchrony to their applications is the JMS API. The combination of JMS messages and message-driven beans is commonly used both as a form of communication between components in collocated applications and as a way to achieve parallelism for local task processing. This approach is cumbersome due to the associated configuration requirements and relative complexity of a messaging API. We plan to address this by integrating simple and lightweight asynchronous capability into the session bean component model.


Welcome to the Blogosphere, Ken!

BTW, I think EJB.lite will be very important, but I'd focus on the developers, not the vendors. The key challenge with EJB today is conceptual complexity. EJB3.0 has a useful subset but most people can't find it because they need to waddle through all the rest. IMO, it is very important that the EJB.lite subset shows through by itself to the developers, with no extra baggage.

- eduard/o

Posted by Eduardo Pelegri-Llopart on March 10, 2008 at 05:58 AM EDT #

Thanks Eduardo. Valid point about EJB Lite. The fact that developers can focus on a smaller API without being distracted by some of the legacy functionality is certainly a benefit. Developers will also benefit by having access to EJB functionality in a wider range of products instead of only Full EE implementations. For example, it's likely that EJB Lite will be supported on top of popular lightweight web containers such as Tomcat. Some similar integrations are available today, but the lack of EJB spec requirements and Java EE TCK compatibility tests for these environments reduces overall application portability.

- ken

Posted by Ken Saks on March 10, 2008 at 06:50 AM EDT #

EJB lite is great news, the standardization of JNDI is highly welcome. My wish list do however also include:

- Timed services in SFSBs. Right now only a SLSB can be timed which means that many people resolve to running quartz jobs to time specific events in a state full bean or simply running their own threads.
- OS interaction. Executing operating system commands is ideally banned but very often needed. EJB needs to target real life scenarios so we need a simple solution for this. Although JMS can solve this it is simply to much work for something you could easily have been done with a monitored thread.
- Stored procedure handling. I know this is JPA (another JSR) but we need official support for calling them. EclipseLink (former TopLink) and Hibernate solves this beautifully by @NamedNativQueries, this just needs to be a standard.

Anyway keep up the good work - Around EJB 2.1 I was ready to abandon it all (Spring came to the rescue) but now with WEbBeans, Seam, Guice, JSF 2... life is looking good as ever.

Posted by Lars Tackmann on March 15, 2008 at 10:06 PM EDT #

I really like the features. In fact, some of them should have been there for ages by now (how come you couldn't initialize a timer easily!). But actually my concern is: will Tomcat/Jetty support it? If they don't there's no hope for EJB 3.1 (lite or not).

Posted by Jose Noheda on March 15, 2008 at 11:46 PM EDT #

The integration with Tomcat/Jetty is important. I have fairly good experience with embedded JBoss (although it has been hard to find any correct information on how to set it up due to the massive JBoss 5 rewrite). Anyway if GlassFish 3 offers a sort of micro container that could be embedded then it would be great.

Another issue is testing. The Spring/Seam solutions works perfectly (although they should be test framework agnostic (TestNG vs Junit)). Ideally I should be able do something like:

class MyTest {
private ShipManager manager;

public void MyTest() {
EJBContainer container = EJBContainer.getInstance();

public void shipTest() {
Ship titanic = manager.findByName("titanic");
assertThat(titanic.getName(), equalTo("titanic");

Similar to the way you inject stuff via Guice injectors. I know this is much to ask, but the current way of testing Servlets (Cactus) and EJB applications is foobar and way more complicated that fx. Spring with Embedded Jetty or Seam with Embedded JBoss.

Posted by Lars Tackmann on March 16, 2008 at 12:11 AM EDT #

Hi Lars,

Thanks for the feedback. Regarding :

Timers in SFSB -- Something we're considering, although the complex component lifecycle makes doing this a bit trickier, which is why it was delayed to this point. There are some pending portability issues in the area of concurrent SFSB access. If we solve those it paves the way for SFSB timers.

OS Interaction -- Can you elaborate on the real-life scenarios you'd like a solution for?

Stored procedure handling -- I recommend pursuing this with the JPA 2.0 EG :

Improved testing -- Good point. Something we've discussed as well. A number of implementations support EJB component instantiation within the client JVM but as you point out there is no standard API. Regardless of the spec outcome it's something that will likely also be supported in GF V3.


Posted by Ken Saks on March 16, 2008 at 11:53 AM EDT #

Hi Jose,

Agreed -- many of the features are LONG overdue :-)

There are already cases where EJB 3.0 is supported on some of the stand-alone web containers (e.g. OpenEJB on Tomcat). But yes, we expect that the modest subset of EJB functionality required by EJB Lite will result in more EJB availability in those kinds of implementations.

The simplified EJB-in-.war packaging plays into this as well, since 1) there's no need for the vendor to add an ejb-jar or .ear deployment mechanism and 2) the same application can be deployed to both a lightweight web container supporting EJB Lite and to a product implementing the full Java EE 6 profile.


Posted by Ken Saks on March 16, 2008 at 12:09 PM EDT #

Hi Ken

Thanks for clearing up these things. The most common issue I have about timers in SFSBs is when I need to schedule some event to rune sometime in future, i.e. executing some job on it say 10 minutes. There is of cause a multitude of problems with this (the bean could have timed out, it may have been eivicted from memory (prePassivate could properly handle this if the timer api would let me disable a pending job)).

Regarding OS interaction, say you want to execute a command on remote system. This s much easier via SSH ('ssh remote@system /path/to/cmd') than setting up a messging system. Espercerly sine you often want to capture the output. I usually ignore the fact that I am not supposed to create threads in session bean and do it this way. From a portability standpoint it is bad practices, but I have seen these issues arise commonly enough to know that this is how people build systems.

As a example. Last week I had to resort to executing ImageMagick's 'convert' command directly in order to convert a PDF into a TIF. There exists converter libaries for Java but non of them would work sufficiently with our contracts - the pragmatic sulution (some might call it a quick hack) was just to spawn a thread which executed the convert command on a remote Linux system and transfered the resulting file back via SFTP.

Posted by Lars Tackmann on March 16, 2008 at 09:45 PM EDT #

Hi Ken.

Thanks for the resume.
I was working with EJB since 2.0 (limitations fixed by our own), then EJB 3. I really like the Java EE platform and I'm looking forward for the new features.

What I would really like is the possibility to hot deploy EJB. This would be a very big advantage for EJB, specially for the developers. Currently the development process for EJB applications is a bit cumbersome, we need to redeploy application server every time an EJB is added or changed.

Do you know about the hot deployment (for development process) support for EJB? Was it mentioned on JCP? Was it considered? Will it be?

Thanks in advance!

Posted by Fernando Montaño on March 19, 2008 at 03:39 AM EDT #

Hi Lars,

Yes, that's one of the basic lifecycle issues with SFSBs and timers. Technically the container can discard an SFSB at any time, including as a result of server shutdown/crash, which is a mismatch with the persistent timer guarantee. There's also the problem that the timer callback can happen while a client invocation(or a different timeout callback) is already in progress on the bean.

The concurrency issue can be solved with the new Singleton component, but that still doesn't address the problem of access to non-persistent state. Assuming the state you need to process within the callback can be represented in a serializable object it can just be passed as the "info" object upon timer creation.

Thanks for describing some additional use-cases. We are investigating ways to support some simple asynchronous operations in a way that's well integrated into the session bean API. That would remove the need to use Java SE threads directly in the EJB tier. I'll be posting some more details on that in a follow-up post.

Posted by Ken Saks on March 19, 2008 at 04:24 AM EDT #

Hi Fernando,

Thanks for your feedback. Hot deployment has typically been left as a value-add for products as opposed to a spec requirement, so it's unlikely we'll address this specifically within EJB 3.1. There's a basic issue with the way classloaders are used in the EE platform that makes supporting hot deployment for any single component challenging. Typically most or all of the classes in an application are loaded by a single classloader, which means everything has to be reloaded when a single thing changes.

From a glassfish perspective we have a couple things to ease redeployment. The first is directory-based deployment. That saves you having to re-issue an asadmin command and transfer the application to the server. We've also significantly reduced the overhead of deployment itself. In the case of EJB deployment we've eliminated all statically generated code from the deployment stage (except for legacy CMP 2.x apps).

Posted by Ken Saks on March 19, 2008 at 04:52 AM EDT #

[Trackback] EJB3.1专家组通过JCP发布了该规范的早期草案 。EJB的新版本期望作为2008年底发布的Java EE 6规范的一部分,它主要面向如下两个方面:简化工作(从EJB3开始)以及增加Java企业社区要求的新特性。主要改变如下...

Posted by elevenXL on April 01, 2008 at 09:31 PM EDT #

Hi Ken

What I'm missing desperatly in EJB 3.0 is a way to access the EntityManager from within entities. I often like yust to invoke a named query inside a Entity, so I don't have to navigate and iterate a whole collection yust to get a desired subset. Especially if I like to implement more OO (object oriented) or DDD (Domain driven design) style, access to the EntityManager inside entities would be desirable.

Reagards Peter

Posted by Peter K. on May 08, 2008 at 08:13 AM EDT #

Hello, I was at your presentation at JavaOne, and I'm just following up on our talk about the timezone and locale parameters for the calendar based timer APIs.


Posted by Mark Collette on May 15, 2008 at 11:43 AM EDT #

I really want the EJB 3.1 functionality right now. It will help simplify the use of EJB technology in portlet applications.

Posted by John Platts on August 16, 2008 at 11:12 AM EDT #

Thanks for the feedback John. We're working on it. You can try out a small amount of EJB 3.1 functionality (.war packaging, no-interface view) right now with the Glassfish V3 Technology Preview 2. See Mahesh's blog for the details : http://blogs.sun.com/MaheshKannan/entry/ejb_3_1_in_glassfish.

We're also planning a preview of some additional features along with the Glassfish V3 Prelude release (http://blogs.sun.com/theaquarium/entry/prelude_to_glassfish_v3). Stay tuned for more info.

Posted by Ken Saks on August 18, 2008 at 04:11 AM EDT #

Out of curiosity is there any new security features planed for EJB 3.1 or do we stick with the expansion defined in JSR 250. I am particularly interested in features more advanced than simple role based security.

Currently it is not trivial to program the following in a portable way:
a) user logins to application (possibly via JDBC realm).
b) user wants to edit a previous order and invokes orderManager.saveOrder(order)
c) backend controls that user actually owns the order he is trying to modify.

The last step is the crucial one, since it require the backendbean to know about the authorized user. This is quite simple using spring-security (acegi) and can be done pr. invocation (i.e. every invocation to the interface requires a security context containing the invoking users username). The upshot of this is that you can actually make the backend bean stateless since each invocation is ensured to have access to the current security principle.

In EJBs this is not as simple (at least not if portability is in mind). Using JAAS to get some simple role based security (@RunAs, @DenyAll...) is easy but once you want to have access to the actual user it becomes hard.

Ideally something like this should be doable:
EJBBinder binder = EJBBinder.getInstance();
// login
LoginManager loginManager = binder.get(LoginManager.class);
User user = loginManager.login(username, password);

// ensure credentials are avalible on all invocations
// (ideally this should be done server side and returned
// to the client, for use in future invocations).
SecurityContext ctx = new SecurityContext();
ctx.bind("user", user);
ctx.setRoles(user.getRole().toString()); // set JSR 250 compatible roles

// invoke some other method that requires access to the security context
OrderManager orderManager = binder.get(OrderManager.class);
: // modify a order for our user

save order could then be a stateless session bean like this:
SecurityContext ctx;

public void saveOrder(Order order) {
User currentUser = ctx.get(User.class);
if(order.getId() < 1) {
} else if(hasAccessTo(user,order)) {
} else {
throw new SecurityException();

This way you can implement your authorization yourself, which is usually way easier than setting up some obscure container based security. And for server side checks you can do whatever you like. Also it would be simple to implement various auth modules similar to acegi (i.e. one for HTTP basic auth (REST/JAX-RS), WS-Security (SOAP/JAX-RS)...).

Of cause it is possible that this is actually doable in a portable way today, in which case I would very much like to know how to do it.

Posted by Lars Tackmann on August 18, 2008 at 04:51 AM EDT #

Hi Lars,

We're not planning to add any security-specific features, although this topic would more likely be addressed as a platform level security enhancement rather than in the EJB spec. Any reason that getCallerPrincipal wouldn't work? It could be stored along with the order in the database.

Posted by Ken Saks on August 19, 2008 at 05:51 AM EDT #

Hi Ken and thanks for your reply

getCallerPrincipal will indeed work, it just works best (easiest) with container based security. What I like about Spring security is the ability to configure the security settings along with the application and not having to rely on specific container setups in order to get security working.

Further with regards to getCallerPrincipal, there is (to my knowledge) no way to bind a a user to it without using container specific mechanisms. Which is quite annoying if I test my application using JBoss embedded but deploy it on GlassFish. Again it is easy to get spring security working across say Embedded Jetty and GlassFish.

Don't get me wrong I am looking forward to EJB 3.1 and have already have very good experience running EJB 3.0 in production (on GlassFish). I Just think that this stuff should be far easier than it is - creating a custom binding of an authorization object (not just a string) should really just be a single standardized method call.

Posted by Lars Tackmann on August 19, 2008 at 07:06 AM EDT #


Posted by juziku on August 07, 2009 at 06:22 PM EDT #

Hi Ken and Lars,
I'm actually involved into an Identity Management project, and I think the EJB 3 platform is very powerfull.
But about the security features, the EJB 3 authorizative engine with is static mapping is quite useless in my RBAC based scenario.
So, my idea is: why do not implement a RBAC sub-system to ensure security and authorization features giving us the desired granularity level?


Posted by Andrea Tomassi on September 29, 2009 at 05:18 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed

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.


« April 2014