What's new in EJB 3.2 ? - Java EE 7 chugging along!

EJB 3.1 added a whole ton of features for simplicity and ease-of-use such as @Singleton, @Asynchronous, @Schedule, Portable JNDI name, EJBContainer.createEJBContainer, EJB 3.1 Lite, and many others. As part of Java EE 7, EJB 3.2 (JSR 345) is making progress and this blog will provide highlights from the work done so far. This release has been particularly kept small but include several minor improvements and tweaks for usability.

  • More features in EJB.Lite
    • Asynchronous session bean
    • Non-persistent EJB Timer service

      This also means these features can be used in embeddable EJB container and there by improving testability of your application.
  • Pruning - The following features were made Proposed Optional in Java EE 6 and are now made optional.
    • EJB 2.1 and earlier Entity Bean Component Contract for CMP and BMP
    • Client View of an EJB 2.1 and earlier Entity Bean
    • EJB QL: Query Language for CMP Query Methods
    • JAX-RPC-based Web Service Endpoints and Client View

      The optional features are moved to a separate document and as a result EJB specification is now split into Core and Optional documents. This allows the specification to be more readable and better organized.
  • Updates and Improvements
    • Transactional lifecycle callbacks in Stateful Session Beans, only for CMT. In EJB 3.1, the transaction context for lifecyle callback methods (@PostConstruct, @PreDestroy, @PostActivate, @PrePassivate) are defined as shown.

      @PostConstruct @PreDestroy
      Unspecified N/A
      Unspecified Unspecified Unspecified Unspecified
      Bean's transaction
      management type
      Bean's transaction
      management type

      In EJB 3.2, stateful session bean lifecycle callback methods can opt-in to be transactional. These methods are then executed in a transaction context as shown.

      @PostConstruct @PreDestroy
      Unspecified N/A
      Bean's transaction
      management type
      Bean's transaction
      management type
      Bean's transaction
      management type
      Bean's transaction
      management type
      Bean's transaction
      management type
      Bean's transaction
      management type

      For example, the following stateful session bean require a new transaction to be started for @PostConstruct and @PreDestroy lifecycle callback methods.

      public class HelloBean {
         private EntityManager em;
         public void init() {
              myEntity = em.find(...);

         @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)    @PostConstruct    public void destroy() {        em.flush();    }

      Notice, by default the lifecycle callback methods are not transactional for backwards compatibility. They need to be explicitly opt-in to be made transactional.
    • Opt-out of passivation for stateful session bean - If your stateful session bean needs to stick around or it has non-serializable field then the bean can be opt-out of passivation as shown.

      public class HelloBean {
          private NonSerializableType ref = ...

      . . .

    • Simplified the rules to define all local/remote views of the bean. For example, if the bean is defined as:
      public class Bean implements Foo, Bar {
          . . .
      where Foo and Bar have no annotations of their own, then Foo and Bar are exposed as local views of the bean. The bean may be explicitly marked @Local as
      public class Bean implements Foo, Bar {
          . . .

      then this is the same behavior as explained above, i.e. Foo and Bar are local views.

      If the bean is marked @Remote as:
      public class Bean implements Foo, Bar {
          . . .
      then Foo and Bar are remote views. If an interface is marked @Local or @Remote then each interface need to be explicitly marked explicitly to be exposed as a view. For example:

      public interface Foo { . . . }

      public class Bean implements Foo, Bar {
          . . .
      only exposes one remote interface Foo.

      Section 4.9.7 from the specification provide more details about this feature.
    • TimerService.getAllTimers is a newly added convenience API that returns all timers in the same bean. This is only for displaying the list of timers as the timer can only be canceled by its owner.
    • Removed restriction to obtain the current class loader, and allow to use java.io package. This is handy if you want to do file access within your beans.
    • JMS 2.0 alignment - A standard list of activation-config properties is now defined
      • destinationLookup
      • connectionFactoryLookup
      • clientId
      • subscriptionName
      • shareSubscriptions
    • Tons of other clarifications through out the spec. Appendix A provide a comprehensive list of changes since EJB 3.1.
    • ThreadContext in Singleton is guaranteed to be thread-safe.
    • Embeddable container implement Autocloseable.

A complete replay of Enterprise JavaBeans Today and Tomorrow from JavaOne 2012 can be seen here (click on CON4654_mp4_4654_001 in Media).

The specification is still evolving so the actual property or method names or their actual behavior may be different from the currently proposed ones.

Are there any improvements that you'd like to see in EJB 3.2 ? The EJB 3.2 Expert Group would love to hear your feedback. An Early Draft of the specification is available. The latest version of the specification can always be downloaded from here.

These features will start showing up in GlassFish 4 Promoted Builds soon.


For 4 years of work this is pretty bad. The only thing I see here are "clarifications" to the specification. Are we moving away from EJB in EE 7 ?

Posted by zztop on November 27, 2012 at 05:52 AM PST #

EJB 3.1 was a pretty significant release and that's why this release is intentionally kept small. Is there any significant EJB feature that you think is missing ?

Read more comments at Marina's blog about the features:


Posted by Arun Gupta on November 27, 2012 at 03:08 PM PST #

Arun, it would be nice if it would be easier to support rich domain models where a service could be easily injected into a pojo.

Posted by zztop on November 27, 2012 at 03:50 PM PST #

Can you elaborate more with a sample ?

Posted by Arun Gupta on November 27, 2012 at 03:55 PM PST #

Arun, from the wording zztop used it looks like he's asking for an (EJB) service to be injected into a JPA entity.

Personally I think this is over the top wrong. It lures programmers into writing code where we end up with cookies that are asked to bake themselves. Somehow some people think this is "realistic" and "the true way of OO".

There was a nice discussion about this on TSS nearly two years ago: http://www.theserverside.com/discussions/thread.tss?thread_id=61669#342747

Posted by guest on November 29, 2012 at 06:18 AM PST #

Pushing business logic into domain model? That sounds like The Path of JDO, which, as far as I know, was officially abandoned. Market has already choosen The Path of Hibernate, which resulted in standardized JPA in JavaEE. Whats the point of coming back to something, which just didnt work? Its like fighting for The Path of Anonymous Inner Classes when The Path of Closures is just around the corner...

Posted by guest on December 04, 2012 at 03:13 AM PST #

yes, the likes of Grails, Rails, Roo, Play, CSLA, and anything DDD (domain driven design) must have got it wrong I guess. Anemic domain model is the way to go.

Posted by zztop on December 06, 2012 at 03:27 PM PST #

Sir is EJBs are still used in companies ??

Posted by guest on December 08, 2012 at 04:06 AM PST #

EJBs is indeed the primary means of writing business logic in Java EE applications.

Posted by Arun Gupta on December 11, 2012 at 06:18 AM PST #

Take into account that we are talking about JavaEE, so when I write about enterprise class applications I mean soa, esb, ws oriented applications, sometimes heterogenic, sometimes clustered. And yes - anemic domain model is the most straight forward way to go for companies looking for stable development. All niche approaches you proposed are considered rather dangerous because of low market adoption when compared to JavaEE, ie. it is much easier to find competent JSF developer than Play developer. Of course, tecnologies you mention can be complementary to those from jee stack, but at their very core is EJB component.

So, if you are looking for some revolutionary, mind-blowing and unfortunately compatibility-breaking technology, I must admit - JavaEE is not the way for you.

Posted by guest on December 11, 2012 at 12:26 PM PST #


if you think that a "rich domain model" is a bad idea for the types of applications you are creating then of course don't do it. However, there are many people who think JSF is/was a bad idea and they stay clear and far from it. They opt for "action based frameworks" over component based frameworks because that's what they know and are more productive with (there are also other considerations here). The point I am trying to make is it's about providing an alternate programming model. I am sure we can agree that there is not just one way to do things ?

Posted by guest on December 12, 2012 at 06:18 AM PST #

In EJB 3.2, I'd definitely like to see an improved @Asynchronous support, with the capability of determining the thread pool size, for example. Some way to name the threads and improve the "trackability" of the work being performed would also be welcome.

I like the move to convention over configuration, for the EJB interface definition/declaration improvement, and would like to see more of that wherever possible in the Java EE spec (especially on the view layer).

And as for the rest of Java EE, please, oh please, get rid of the JSF scopes and adopt CDI once and for all. And DO have a look at the extensions provided by projects such as Apache's CODI.

Posted by rodrigo on December 12, 2012 at 07:38 AM PST #

Unfortunately it's not as simple as it looks - read David Blevin's comments in the JIRA opened on this feature: http://java.net/jira/browse/EJB_SPEC-9.

Feel free to add a comment, ideas, or a full proposal for the solution.

Posted by marina vatkina on December 12, 2012 at 03:58 PM PST #

My comment above was for the 1st part of Rodrigo's comments.


Posted by marina vatkina on December 12, 2012 at 04:09 PM PST #

Its my option
Just wait the Spring to avoid to face again as ....
the redefine as 2 to 3.

Posted by neo-euerka on December 12, 2012 at 08:59 PM PST #

@Marina, the link you've posted throws a 'project does not exist' error, although I was able to read it briefly yesterday. I understand extending @Asynchronous functionality might not be as simple as expected, but then again, weren't any extensions envisioned when it was thought of in the first place?

And as for the changes on JSF, I mean it. CDI (through Seam, for example) has proven to be much more flexible and productive then the JSF scopes counterparts. I understand the need for backward compatibility, but I'd favor improving CDI in JSF over any changes to the JSF scope engine itself.

Posted by rodrigo on December 13, 2012 at 05:21 AM PST #

To rodrigo:

Despite the obvious need to secure server`s resources (aka limit threads responsible for asynchronous request processing in this case) maybe Message Driven Bean suits your needs better here...?

Yes, there are many ways to do many things. But imagine how bloated would JEE be, if all these alternative aproaches were parts of this super-specification and how many resources (time, people, knowledge...) would be needed to produce first draft... I think thats simply impossible. JEE has choosen its consistent and stable path of development (call it growth) focused on enterprise class solutions and everybody is welcome to provide feedback, which fits JEE philosophy. If JEE is not smbd`s way, he/she is of course free to use technology from Apache, Google etc...

Posted by guest on December 17, 2012 at 02:13 AM PST #

>yes, the likes of Grails, Rails, Roo, Play, CSLA, and anything DDD (domain driven design) must have got it wrong I guess. Anemic domain model is the way to go.


I'd rather call it a "slim domain model", but naming aside. Why do you think it's natural to ask a cookie to bake itself? Doesn't the actual domain has an Oven which has the functionality to -bake- a Cookie?

Posted by guest on December 19, 2012 at 03:38 AM PST #

I suspect you meant to say "*SessionContext* in Singleton is guaranteed to be thread-safe".

Posted by Brett Kail on December 21, 2012 at 09:03 AM PST #

EJB 3.2 this is Greate. i want webbase application without HTML tag.I fing this in your plateform with good thing like busness logic process by ejb at server. i am dotnet programmer. i developed 250 project of account for desktop in last 12 years, and still this project continue and active.i am new for java group but one thing i notice that java is great for development and java + jee + ejb is great things i am reading all information from your web in last 6 month. you do all good and greate.

Posted by Prashant i desai on January 15, 2013 at 07:22 PM PST #

Sir, is any company still investing in EJB's

Posted by Nik Skateas on April 30, 2013 at 06:07 AM PDT #

> Sir, is any company still investing in EJB's

Sure, that's the way to go and that's what happens ;-)

Posted by Yannick Majoros on June 19, 2013 at 02:05 AM PDT #

I might have missed it but something like a @Clustered @Singleton combination would be useful.

Posted by guest on June 25, 2013 at 01:57 PM PDT #

Post a Comment:
Comments are closed for this entry.

profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.

Java EE 7 Samples

Stay Connected


« July 2016