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

Guest Author

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 (href="http://jcp.org/en/jsr/detail?id=345">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
  • 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.










      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.









      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(...);

         public void destroy() {

      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 href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4654">Enterprise
JavaBeans Today and Tomorrow from JavaOne 2012 can be href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4654">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 href="http://java.net/projects/ejb-spec/lists/users/archive">hear
your feedback. An href="http://download.oracle.com/otndocs/jcp/ejb-3_2-edr-spec/index.html">Early
Draft of the specification is available. The latest version
of the specification can always be downloaded href="http://java.net/projects/ejb-spec/downloads">from here.

  • href="https://wikis.oracle.com/display/GlassFish/PlanForGlassFish4.0#PlanForGlassFish4.0-SpecificationStatus">Java
    EE 7 Specification Status
  • EJB Specification
  • JIRA of EJB

  • href="http://java.net/projects/ejb-spec/lists/users/archive">JSR
    Expert Group Discussion Archive

These features will start showing up in href="http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/">GlassFish
4 Promoted Builds soon.

Join the discussion

Comments ( 23 )
  • zztop Tuesday, November 27, 2012

    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 ?

  • Arun Gupta Tuesday, November 27, 2012

    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:


  • zztop Tuesday, November 27, 2012

    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.

  • Arun Gupta Tuesday, November 27, 2012

    Can you elaborate more with a sample ?

  • guest Thursday, November 29, 2012

    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

  • guest Tuesday, December 4, 2012

    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...

  • zztop Thursday, December 6, 2012

    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.

  • guest Saturday, December 8, 2012

    Sir is EJBs are still used in companies ??

  • Arun Gupta Tuesday, December 11, 2012

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

  • guest Tuesday, December 11, 2012


    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.

  • guest Wednesday, December 12, 2012


    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 ?

  • rodrigo Wednesday, December 12, 2012

    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.

  • marina vatkina Wednesday, December 12, 2012

    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.

  • marina vatkina Thursday, December 13, 2012

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


  • neo-euerka Thursday, December 13, 2012

    Its my option

    Just wait the Spring to avoid to face again as ....

    the redefine as 2 to 3.

  • rodrigo Thursday, December 13, 2012

    @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.

  • guest Monday, December 17, 2012

    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...

  • guest Wednesday, December 19, 2012

    >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?

  • Brett Kail Friday, December 21, 2012

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

  • Prashant i desai Wednesday, January 16, 2013

    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.

  • Nik Skateas Tuesday, April 30, 2013

    Sir, is any company still investing in EJB's

  • Yannick Majoros Wednesday, June 19, 2013

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

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

  • guest Tuesday, June 25, 2013

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

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.