Community
Participate
Working Groups
Build Identifier: 2.0.0 I have an entity (EntityA) that maps an embeddable type (EmbeddableType) using ElementCollection with CollectionTable into a Map, where the property 'language' of EmbeddableType is defined as map key (see enclosed test case for details). Simply creating instances of EntityA and persisting it, works fine (see test testSimplePersist) When modifying the mapped association by adding or removing a Map entry, EL throws a NullPointerException in MapContainerPolicy.compareKeys(MapContainerPolicy.java:234) (see enclosed stack trace for details) when the transaction is committed. Reproducible: Always Steps to Reproduce: 1. Apply test case (TestNG) in attached file
Created attachment 154886 [details] Entity definition and test case
Created attachment 154887 [details] Stacktrace
The problem seems to be that the MapContainerPolicy.compareKeys() method is not null-safe. It creates a key from an object that was not in the session before, and all its values are nulls, and then it extracts the map key field from this object, which is null. Possible solution to this problem is a slight change to the compareKeys() method: public boolean compareKeys(Object sourceValue, AbstractSession session) { if (((UnitOfWorkImpl)session).isClassReadOnly(sourceValue.getClass())) { return true; } Object backUpVersion = ((UnitOfWorkImpl)session).getBackupClone(sourceValue, getElementDescriptor()); Object backUpVersionKey = keyFrom(backUpVersion, session); Object sourceValueKey = keyFrom(sourceValue, session); if (backUpVersionKey == sourceValueKey) { // this conditional captures the same instances, as well as both being nulls // not sure if this semantics is correct return true; } if (backUpVersionKey == null && sourceValueKey != null) { return false; } // if sourceValueKey is null, and backUpVersionKey is not, it's probably OK since most equals() Regards. // implementations deal with it correctly return backUpVersionKey.equals(sourceValueKey); }
2_1_community Setting target and priority. See http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines for details of what these values mean.
Rising priority to major since this bug prevents us from using standard Glassfish server distribution.
Hi again, I am raising the priority of this bug again after checking 2.1.0 RC1 from May 17, 2010 and does not contain the fix. Using map keys for this kind of mapping comes really natural in my opinion and it's an important addition to the spec. It's one of the reasons we are using JPA 2. Further on, the spec has been finalized 8 month ago. I think it's about time that the new features will work now. Szczyp has provided a fix for the problem which has shown to be working and the fix seems to be kind of simple (and obvious). However, fixing the problem ourselves prevents us from using standard EL integration in Glassfish, which blocks us from using standard Glassfish distribution. I would really appreciate if the fix makes it into 2.1. Even better if a backport to 2.0 is made. Thanks!
Proposed fix looks good. 2.1 is closed, but fix will be checked into 2.1.1.
changing target unti
Created attachment 171638 [details] Fix described above + testing
Checked in suggested fix into trunk. Setting bug to P1 for 2.1.1, so it will be included in 2.1.1 when the stream opens. Reviewed by: Tom Ware - reviewed community-submitted fix Add mapping and test to Inherited model and tested with JPA and Core LRG
Changes have been submitted to the 2.1.1 stream.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
