Table of Contents
The following sections indicate changes that are incompatible between OpenJPA 1.3 and prior releases. Some may require application changes. Others can be remedied through the use of compatibility options.
The Query interface setParameters() method behavior has changed to throw an ArgumentException if more parameter substitutions are supplied than defined in the createQuery() or createNamedQuery() call, as required by the JPA2 specification. OpenJPA 1.2.x and prior versions would silently ignore the supplied parameter substitutions and allow the Query to be processed.
Currently, when an entity is serialized after calling EntityManager.find(), detach() or detachAll() then all Section 6.4, “ Proxies ” are removed as expected, but when the same entity instance is serialized after calling EntityManager.clear() the proxy classes are not removed.
This has two side-effects: when entities are remoted across JVM boundaries (RPC) or deserialized the OpenJPA runtime must be available on the classpath (both client and server containers); when entities are deserialized the OpenJPA runtime must be the exact same revision as used to serialize the entities due to the $proxy classes using dynamically generated serialVersionUID values.
Starting with OpenJPA 2.0, this behavior has been
modified, so that by default all proxies will be removed
See Section 1.3.1, “
on how the behavior changes based on the
DetachedStateField setting along with
how to override the default behavior.
For this release of OpenJPA, you can manually enable this new behavior by setting the following openjpa.Compatibility property as follows:
If an entity was updated between the persist() and commit() operations in OpenJPA 1.x, then any PreUpdate and PostUpdate life cycle callback methods would be executed. Starting in OpenJPA 1.3 and 2.0, these callbacks will not get executed.
The JPA 2.0 specification section on "Semantics of the Life Cycle Callback Methods for Entities" has been updated to include a Note that the callback behavior for updating an entity after the persist operation is implementation specific and should not be relied upon.