Community
Participate
Working Groups
This bug is filled from data provided in GlassFish bug https://glassfish.dev.java.net/issues/show_bug.cgi?id=12849 Please see attached test case that reproduces the bug. To run the test case 1. Modify build.properties to point to your development environment 2. Modify test.properties to point to your database 3. Execute "ant agent run"
Created attachment 175914 [details] Test case reproducing the issue
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
This bug basically results in corrupted cache at every merge() that may cascade to a Map collection, every subsequent read results in incorrect data. Shouldn't it be scheduled for the next release? It's a pretty serious show stopper in my opinion.
2.1.2 is the next release it could appear in. 2.1.1 is closed for check-ins.
We may have a few more days. Looking into the possibility of integrating into 2.1.1.
When I run the test case on our latest code, I get the following output: New Fetch > Key: 0 childProperty: 0 After Merge > Key: 1 childProperty: 1 New Fetch > Key: 1 childProperty: 1 According to the comments, this is correct. Have you tried the test on the most recent code?
Note: I have tested on 2.1 and trunk tips code and output is the same.
The test case works for me too. It is possible that for my initial testing I might have used an older version of EclipseLink
If you can provide a test case that reproduces the bug, please feel free to reopen this bug. Also, please confirm the version of EclipseLink you see the issue on and if it is not a 2.1-stream version, try the latest. We did quite a number of map fixes for 2.1.
I was testing in Glassfish v3 Final, which I believe ships EclipseLink 2.0 binaries. Unfortunately I can't swap to a nightly build due to internal policies, but I can update Glassfish v3 to EclipseLink v2.1 I'm following this guide: http://blogs.sun.com/GlassFishPersistence/entry/updating_eclipselink_bundles_in_glassfish However replacing the corresponding jars results in a java.lang.ClassNotFoundException: org.eclipse.persistence.jpa.PersistenceProvider Any thoughts?
Trashing the osgi-cache folder resolved the EclipseLink upgrade issue on Glassfish. I tested the original issue with EclipseLink 2.1 and I can confirm that it works correctly. Thanks for looking into it.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink