What's new in EJB 3.2 ? - Java EE 7 chugging along!
- by arungupta
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
@PrePassivate
@PostActivate
Stateless
Unspecified
Unspecified
N/A
N/A
Stateful
Unspecified
Unspecified
Unspecified
Unspecified
Singleton
Bean's transaction
management type
Bean's transaction
management type
N/A
N/A
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
@PrePassivate
@PostActivate
Stateless
Unspecified
Unspecified
N/A
N/A
Stateful
Bean's transaction
management type
Bean's transaction
management type
Bean's transaction
management type
Bean's transaction
management type
Singleton
Bean's transaction
management type
Bean's transaction
management type
N/A
N/A
For example, the following stateful session bean require a new
transaction to be started for @PostConstruct and @PreDestroy
lifecycle callback methods.
@Statefulpublic class HelloBean { @PersistenceContext(type=PersistenceContextType.EXTENDED) private EntityManager em;
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) @PostConstruct 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.
@Stateful(passivationCapable=false)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:
@Statelesspublic 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
@Local@Statelesspublic 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:
@Remote@Statelesspublic 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:
@Remotepublic interface Foo { . . . }@Statelesspublic 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.
Java
EE 7 Specification Status
EJB Specification
Project
JIRA of EJB
Specification
JSR
Expert Group Discussion Archive
These features will start showing up in GlassFish
4 Promoted Builds soon.
