Community
Participate
Working Groups
Probably an unlikely use case, but leads to the update thread running infintitely. An easy way to reproduce is to add java.util.logging.LogManager.LogNode to the orm.xml file. How I managed to hit this is not important :) In AbstractJpaProject.getJavaResourcePersistentType(typeName) the typeName and qualifiedName don't match because the type name uses a '.' for the inner class and the qualified name uses '$'. This leads to that BinaryPersistentType being rebuilt during update and the virtual persistent attributes not matching when updating the OrmPersistentType.
Consider for RC4, depending on the fix. If at all risky, we can push this to 2.2.1.
Created attachment 138367 [details] candidate patch Minor tweaks to get dot-separated name from IType.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This bug can result in data loss, since when encountered the user must forcefully kill the eclipse process to proceed. I have it marked as Major instead of Critical since the case is not "main-path", but is certainly a valid and possible use case. * Is there a work-around? If so, why do you believe the work-around is insufficient? There is no workaround, except for the user to avoid this particular mapping case. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This fix has been tested by Brian, Karen, and myself. We have done ad-hoc testing to look for regressions, and have run the JUnit tests. * Give a brief technical overview. Who has reviewed this fix? AbstractJpaProject.getJavaResourcePersistentType(typeName) will now find referenced static inner classes since we now get a fully qualified, dot-separated name for static inner classes from the IType. This should only affect nested classes that are external to the JPA project or in binary form. * What is the risk associated with this fix? I am only proposing this change due to the fact that the fix is low risk. If it was medium risk, I would recommend this for the first service release. I think that the risk of the fix is appropriate for RC4 since the bug is pretty severe.
Low risk fix for 'major' severity issue.
I think borderline, sine described as "an unlikely use case" but the problem does seem bad, and the fix especially simple and isolated, so I approve.
Committed and released into R2_2_maintenance branch, and also committed into HEAD.
Looks like we lost David's +1 flag by accident.
And mine.
Verified in wtp-sdk-S-3.1RC4-20090608061637.
