Thursday Apr 04, 2013

EJB 3.2 Final Release Candidate is available for review

This is your chance to make sure that the EJB 3.2 spec and javadoc are correct!

The files for review are available in the project download area. All comments must be submitted before noon PT on April 9th to be considered for inclusion.

Final Release Candidate of the Core Doc
This is the list of changes as specified in the Revision History:

  • Editorial changes
  • Specified that the unqualified bean class name can be used as the value in the method-name element to bind constructor-level interceptors
  • Simplified requirements for definition of a security role using the ejb deployment descriptor
  • Restricted use of JTA transactional interceptors with EJBs
  • Aligned environment entries requirements with the Java EE Platform specification
  • Noted that if a transaction had been marked for rollback, the value of the application exception rollback element has no effect
  • Updated "What is New in This Release"
  • Updated XML Schema definition to the latest version
  • Clarified that no-interface view and no-methods interface message listener methods are non-static public methods
  • Removed restriction on final modifier for methods which are not exposed through a no-interface view or are not message listener methods with no-methods interface

Final Release Candidate of the Optional Doc

The changes are all editorial

javadoc for Final Release Candidate

Minor changes to the package.html

Friday Mar 15, 2013

EJB 3.2 Proposed Final Draft is available for review

We are on the final stretch for the EJB 3.2 release. The PFD documents and javadocs can be downloaded from the JCP page or the project.

The major changes include

  • EJB API groups (see Section 16.1 for more detail)
  • Support for MDBs with a no-method message listener interface (see Section 5.4.3 for more detail)
  • Container defined security role "**" (see Section 12.3.1 for more detail)

These are the spec changes since the Public Draft as noted in the Change Log:

  • Minor editorial changes
  • Updated rules for the activationConfig properties to reflect changes to the JMS specification. Removed section "Durable Subscription Name in Clustered Deployment"
  • Moved chapter "Specification of Interceptors in the Deployment Descriptor" from the Interceptors specification back to this document
  • Added that PostActivate, and PrePassivate lifecycle callback methods follow requirements for the lifecycle callback interceptor methods defined in the Interceptors specification
  • Noted the a message-driven bean class may declare a constructor using Inject annotation in addition to a no-arg constructor, if it is a CDI-enabled bean
  • Added AroundConstruct to the list of supported lifecycle callback methods.
  • Added references to the Interceptors specification for bean instance creation rules if AroundConstruct callback is declared on the associated interceptor class
  • Added around-construct interceptor type to the list of deployment descriptor elements used to specify the interceptor methods of an interceptor class
  • Replaced newInstance() with a bean constructor to allow for Inject constructor use cases
  • Updated to the final versions of the related documents
  • Removed explicit 3.2 version where it is not needed
  • New: Defined EJB API Groups.
  • Renamed Subsection "EJB Lite" to Subsection "EJB Lite and Other EJB API Groups".
  • Replaced table "Required contents of EJB Lite and Full EJB API" with "EJB API Groups".
  • Added section 16.1.1, "Support for Other EJB API Groups in an EJB Lite Container".
  • Added section 16.1.2, "Integration with Other Technologies".
  • Updated related Embeddable Container requirements (18.3.1) to not require .war file support
  • Updated XML Schema definition to the latest version
  • Added section on relationship to the JAX-RS Specification
  • New: Added Container provided security role named "**" to indicate any authenticated caller independent of the actual role name
  • Adjusted section 11.4, "Simple Environment Entries", and fixed the list of the naming context that the container must implement to be consistent with the Java EE Platform specification
  • Added lookup-name to a deployment descriptor override rules for a Resource annotation
  • Replaced description of the resource-ref and the resource-env-ref elements with the references to the Java EE Platform specification
  • Updated section 16.3.5, "JMS API Requirements" to reflect the latest requirements in the JMS specification
  • Updated sections 16.3.3 and 16.3.4 to match the latest versions of the corresponding specification
  • Replaced footnote in section 4.6.5, "Disabling Passivation of Stateful Session Beans" with a text note on failover of stateful session beans and use of passivation
  • New: Added message-driven bean with a no-method listener interface
  • Updated "What is New in This Release"

Wednesday Oct 10, 2012

The latest version of the EJB 3.2 spec available on project

If you are not following us on the users alias, here is a quick update.

Just before JavaOne, I uploaded the latest version of the EJB 3.2 Core document to the downloads. If you want to see the detailed changes, download it

If you are interested in the high-level list, or would like to know what to look for, this is the list of changes since the previous version (found on the same download page):

  • Specified that the SessionContext object in a the singleton session bean is thread-safe

  • Clarified that the EJB timers distribution and failover rules apply only to persistent timers

  • Clarified that non-persistent timers returned by getTimers and getAllTimers methods are from the same JVM as the caller

  • Fixed section numbering (left over after moving it to its own chapter) in Ch 17

  • Noted that only 3.0 and 3.1 deployment descriptors are required to be supported in EJB 3.2 Lite for prior versions of the applications

  • Fixes for EJB_SPEC-61 (Ambiguity in EJB lite local view support) and EJB_SPEC-59 (Improve references to the component-defining annotations)

  • JMS/MDB changes: added new standard activation properties and the unique identifier, and rearranged sections for easier navigation

  • Fixed unresolved cross-refs

  • Updated the rule: only local asynchronous session bean invocations are supported in EJB 3.2 Lite

  • Synchronized permissions in the Table with the permissions listed for the EJB Components in the Java EE Platform Specification Table EE.6-2

  • Specified that during processing of the close() method, the embeddable container cancels all pending asynchronous invocations and non-persistent timers

  • Updated most of the referenced documents to their latest versions

Happy reading!

Wednesday Mar 23, 2011

EJB is moving forward. We plan to submit a JSR for EJB 3.2 to the JCP shortly. Linda DeMichiel and I will be leading this JSR, and we will be keeping you posted as work on it progresses.

You'll be able to follow us on our blogs or the JCP page when it becomes available.

Tuesday Oct 21, 2008

Using EJB Timer Service in GlassFish V3 Prelude

This is a followup to the previous entry Using EJB Timers in GlassFish V3 TP2

All steps described in that blog apply, with the exception that the war file name and location had slightly changed to be <your-installtion>/glassfish/lib/install/applications/ejb-timer-service-app.war (Note that there is now no version present in the name of the war archive).

With V3 Prelude you can now use the EJB Timer Service with the Embedded JavaDB database, as had been available in all prior releases of GlassFish and Sun Application server.
To do so, just install JTS package from the Update Center and restart the server. You need JTS support because the __TimerPool is configured to use XA resources.

As always send us questions or comments to or

Sunday Nov 19, 2006

Persistence thought of the day

The Java Persistence API defines an EntityManager.close method. After this method is called on an entity manager instance, it is still possible to call methods isOpen and getTransaction on that instance.

While it's clear why the former is allowed, the same requirement for the getTransaction method sounds strange at first glance. For the answer, let's look in the spec itself. In the section 3.1.1 EntityManager Interface, the javadoc for the EntityManager.close contains the following text:

If this method is called when the EntityManager is associated
with an active transaction, the persistence context remains
managed until the transaction completes.

This means that by allowing to call this method on a closed entity manager, the spec allows you to check the status and complete the transaction. (Of course this is all about the resource-local entity manager.)

Let me know, if it's still not clear...

Friday Aug 04, 2006

Reading Java Persistence API spec #2

Today we'll look into the following sections of the spec and see how they can affect us in unexpected way:

3.1.1 EntityManager Interface

\* Clear the persistence context, causing all managed
\* entities to become detached. Changes made to entities that
\* have not been flushed to the database will not be
\* persisted.
public void clear();

3.2.2 Removal

The semantics of the remove operation, applied to an entity X are as follows:

  • If X is a new entity, it is ignored by the remove operation.

  • If X is a detached entity, an IllegalArgumentException will be thrown by the remove
    operation (or the transaction commit will fail).

Now let's look at the following code (which does not depend on whether it's executed in a Java EE or in a Java SE environment):


E e = new E(...);


// prints 'false'


This code will behave quite differently, depending on the actual steps in the method maybeCommitTransaction()!

If maybeCommitTransaction() is a no-op, entity 'e' actually becomes new again after clearing the persistence context, and it's ignored by the remove operation.

If maybeCommitTransaction() is a commit followed by a begin of a new transaction, entity 'e' becomes detached and remove will throw an IllegalArgumentException or commit will fail.

Note: em.contains(e) will return false in both cases.

If you are still confused, think about it in this way: a detached instance has a database state associated with it.

Thursday Jun 29, 2006

Reading Java Persistence API spec

Let's look at the following section of the spec:

3.2.3 Synchronization to the Database

The semantics of the flush operation, applied to an entity X are as follows:

  • If X is a managed entity, it is synchronized to the database.

    • For any entity Y referenced by a relationship from X, where the relationship to Y has
      not been annotated with the cascade element value cascade=PERSIST or cascade=ALL:

      • If Y is new or removed, an IllegalStateException will be thrown by
        the flush operation (and the transaction rolled back) or the transaction commit
        will fail.

The last bullet is an interesting requirement. Please read it carefully (and may be more than once...).

This requirement means that if you have in a transaction entities X and Y with relationship between them, and you remove an entity Y, you must nullify all references to Y, or your transaction will fail. This is true even if Y owns the relationship (i.e. if FK column belongs to the table that Y is mapped to).

It also means that if you have such relationship marked with cascade=ALL, the removal of Y will be reverted (!) - see section 3.2.1 Persisting an Entity Instance on semantics of the persist operation, applied to a removed instance.

Food for thought... Let me know if you need more detailed explanation :)

Tuesday Apr 25, 2006

Testing standalone Java Persistence bundle

Yes, I tried it, and it works :)

1. Download the latest bundle from the page and install it following the instructions. The bundle will be unpacked to ./glassfish-persistence directory.

2. Download the Java SE example from the example page: and unzip it. There are rumors that the link to the zip files does not work, but I couldn't reproduce the problem on Solaris or Windows.

3. Copy classes/META-INF/persistence.xml.template to classes/META-INF/persistence.xml and set your database and driver properties. Create the tables using sql/tables_oracle.sql or modify it for your database

4. Change location to classes directory, and execute the test:
java -cp [driver-location]:. -javaagent:[install-location]/glassfish-persistence/toplink-essentials-agent.jar client.Client

You should see the expected output:

Inserting Customer and Orders... OK
Verifying that all are inserted... OK
Removing all... OK
Verifying that all are removed... OK

i) toplink-essentials.jar is automatically added to the classpath by the manifest in the agent jar.
ii) All javax.persistence API and xml schemas are part of the toplink-essentials.jar, which means that you don't need any other jar in the classpath for the compilation.
iii) You can skip the -javaagent call if your environment doesn't allow to plug in the agent - the only side effect is loading all relationship as EAGER.


Marina Vatkina


Top Tags
« February 2017

No bookmarks in folder

Related Links