If you didn't know what is coming in EJB 3.2...

This is the list of changes in the latest EJB 3.2 draft:



  • Support for the following features has been made optional in this release and their description is moved to a separate EJB Optional Features document:

    • EJB 2.1 and earlier Entity Bean Component Contract for Container-Managed Persistence

    • EJB 2.1 and earlier Entity Bean Component Contract for Bean-Managed Persistence

    • Client View of an EJB 2.1 and earlier Entity Bean

    • EJB QL: Query Language for Container-Managed Persistence Query Methods

    • JAX-RPC Based Web Service Endpoints

    • JAX-RPC Web Service Client View


  • Support for local asynchronous session bean invocations and non-persistent EJB Timer Service has been added to the EJB 3.2 Lite set of features

  • Restriction on obtaining the current class loader has been removed

  • Access to Java I/O has been relaxed, replacing ‘must not’ with ‘should exercise caution’

  • Lifecycle callback interceptor methods of stateful session beans can now be executed in a transaction context (determined by the lifecycle callback method's transaction attribute)

  • It is now possible to completely disable passivation of a specific stateful session bean

  • TimerService API has been extended for an ability to query all active timers in the same EJB module

  • Default rules for designating implemented interfaces for a session bean as local or as remote business interfaces has been relaxed to include more than one interface (see examples in the document for the detailed rules)

  • List of standard activation properties for JMS message-driven beans has been extended to match the changes in the JMS 2.0 specification

  • A unique identifier of a JMS message-driven bean can be now looked up by a standard name by the JMS resource adapter to construct a subscription name

More details and get involved


If you are interested in reading the latest draft, it is available for download on the EJB spec java.net project page: http://java.net/projects/ejb-spec. On this page you can also subscribe to the users mailing list to read the ongoing discussions and provide your input.

Comments:

What about having transaction attributes on pojo's that are not EJB's ?

Posted by guest on July 31, 2012 at 06:47 AM PDT #

This is being discussed in the Java EE Platform and the JTA EGs. If the outcome of this discussion results in any changes in the EJBs, we will adjust accordingly. But most probably EJBs will continue to use transactions without any changes, and POJOs will have JTA annotations to opt in.

Posted by marina on July 31, 2012 at 10:52 AM PDT #

EJB is a great technology, but the above list largely looks like something for a maintenance release. Mostly some formal changes and clarifications.

Timer Service is really the only real feature on this list. If we can query all timers, does that mean we can also finally see where they are stored and provide a custom location?

Posted by guest on July 31, 2012 at 03:32 PM PDT #

Well, you can't make anything optional in a maintenance release. The rest are small features, but they add up. It's unfortunate that 3.1 with all its changes was designated as a point release. If it would have been called 4.0, the current version would be less confusing.

The custom location of the Timer Service was rejected by the EG.

Posted by marina on July 31, 2012 at 03:49 PM PDT #

What about the EJB 2.1 and before home interfaces? Things like EJBHome, EJBLocalHome, HomeHandle, etc. Can they be made optional as well?

Posted by guest on August 01, 2012 at 04:27 AM PDT #

Eventually. But read the platform spec for how optionality is a 2-step process.

Posted by marina on August 01, 2012 at 10:08 AM PDT #

Hmmmm, can the first step be done for EJB 3.2? Those types are completely irrelevant to modern day EJB programming and only serve as an ugly reminder to how bad things were in the past.

Posted by guest on August 02, 2012 at 06:48 AM PDT #

You would be surprised how many projects are still running on 2.x interfaces. But we do have an open RFE to make them optional - you can add your vote.

Posted by marina on August 13, 2012 at 02:13 PM PDT #

JMS enhancements look good for me, although I still hesitate to use EJB.

Posted by guest on August 13, 2012 at 06:15 PM PDT #

You don't need to use 2.x interface if you don't want. Why do you hesitate to use EJBs in general?

Posted by marina on August 14, 2012 at 11:51 AM PDT #

>Why do you hesitate to use EJBs in general?

Marina, I can't talk for the previous commenter but in my honest opinion things like those EJB 2 classes are scaring people away. I know it's difficult, but a pure EJB 3 version that's completely cleansed from any EJB 2 baggage would help a lot.

Projects that still run on EJB 2.x can just continue to use whatever they are running on now, can't they?

But maybe the only solution is dissolving EJB into a set of separate services that can be applied to CDI managed beans. That would effectively gives us an EJB without any trace of EJB 2 legacy.

Posted by Ruben on August 14, 2012 at 02:10 PM PDT #

>But maybe the only solution is dissolving EJB into a set of separate services that can be applied to CDI managed beans. That would effectively gives us an EJB without any trace of EJB 2 legacy.

Yes, that is the general direction that we are targeting. We decided to start with the transactions, that ended up to be more complicated that we originally thought. I think that eventually, EJB 2 will become optional, and EJBs will differ from CDI managed beans in that the former will come with all services by default, and the latter will need to opt in into them.

Posted by marina on August 14, 2012 at 02:32 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Marina Vatkina

Search

Top Tags
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
News

No bookmarks in folder

Blogroll
Related Links