Hi James,
This does not quite work as intended, I believe. Setting
descriptor.getInheritancePolicy().setDescribesNonPersistentSubclasses(true);
will cause all inheriting classes to be persistent and makes
eclipselink expect a class discriminator column (I am using eclipselink
1.1.0).
In addition, the entity class is _dynamically_ enhanced at runtime,
thus it's class does not match the type defined in the persistence unit.
Furthermore, it's quite possible that non-enhanced and enhanced
versions of the same entity type are persisted. This results in three
problems:
1.) With the above setting, inheriting classes are regarded as
persistence-capable, even if they are not
2.) Eclipselink expects a discriminator column for types supporting
persistence for non-entity subclasses. However, the expected
discriminator column was not generated during pre-deployment (Maybe
because the entity type was not enhanced at that point), thus a NPE
occurs when querying the table of the entities whos inheritance policy
supports non-persistent subclasses
java.lang.NullPointerException
at
org.eclipse.persistence.internal.sessions.AbstractRecord.get(AbstractRecord.java:270)
at
org.eclipse.persistence.descriptors.InheritancePolicy.classFromRow(InheritancePolicy.java:327)
(As getClassIndicatorField() of InheritancePolicy returns null)
3.) The Persistence Context commits inconsistently as the commit-order
is build upon a direct comparison of the entity type
referenced in the persistence unit and the type of the entity in
the context (in CommitManager):
// The commit order is all of the classes ordered by
dependencies, this is done for deadlock avoidance.
for (Enumeration classesEnum = getCommitOrder().elements();
<-- from persistence unit
classesEnum.hasMoreElements();) {
Class theClass = (Class)classesEnum.nextElement();
...
if (objectToWrite.getClass() == theClass) { <--
compares Persistence-unit type with runtime type
The latter comparison leads to the commit manager ignoring the
enhanced entities by not adding them to
the set of changed objects to commit.
Looking at this I believe introducing support for entity proxies does
still require a significant amount of work...
I shall file an issue.
Best,
Olaf
James Sutherland wrote:
This works by default in the native API, but in JPA a check was added to
ensure the object's class was correct.
You can disable this check by using a DescriptorCustomizer or
SessionCustomizer to set,
descriptor.getInheritancePolicy().setDescribesNonPersistentSubclasses(true);
However, please log a bug for this, as this setting should not be on
inheritance policy, as it must be supported for descriptors without
inheritance as well. It should also be reconsidered to be disabled by
default, as CGLib and subclasses are quite common.
Olaf Otto wrote:
Hello eclipselink users,
I am wondering whether eclipselink supports entities that are proxied by
CGlib at runtime.
I have the following situation: If certain entity classes are loaded
from the persistence layer, their instantiation strategy may proxy them
to support custom lazy-loading behavior (thats a long story, short).
After implementing this i realized that - not quite unexpected -
eclipselink could no longer retrieve the ClassDescriptor metadata for
the enhanced entity type, nor could modifications to instances of the
type be commited. Apparently, there are quite a number of
<entity>.getClass() == <x> checks and other direct usages of the entity
type in eclipselink which effectively prevent proxy usage.
Am i correct or is there a way to proxy entity types without these
sideeffects?
Best,
Olaf
-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
|