[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipselink-users] Long shot: EclipseLink 2.1.1, inheritance, primary keys
|
I have a situation that is almost certainly pilot error, but involves EclipseLink at deployment time.
I have an .ear file with a bunch of JPA jars in it. Everything was deploying and running fine yesterday.
I changed my project's version numbers--that was it--and rebuilt and reinstalled the .ear file.
EclipseLink 2.1.1 as integrated into Glassfish 3.1b21 promptly complained that one of my JPA classes didn't define any primary keys. This class happens to extend from a @MappedSuperclass, which happens to extend from another @Entity. No source code has changed; as I said, this hierarchy worked fine on the same build yesterday.
I did some svn diffing and confirmed that the source code in all artifacts had not changed.
I did some .ear surgery and replaced the binary jar inside the ear with the old copy. Deployment was successful. WTH?
So I could tell that the deployment problems were caused by something different between the two jars: my version 1.1 of my JPAs, and my version 1.0-SNAPSHOT.
So I examined each .jar file in Emacs' ediff tool, which helpfully displays byte sizes and whatnot. Both jars are byte-for-byte size-identical, as I would expect them to be.
So then: two JPA jars, byte-for-byte identical. .ear file works with one of them, but not with the other.
Are there any known issues of any kind around how EclipseLink 2.1.1 determines primary keys when there's an inheritance hierarchy like this? Or...? Totally mystified as to where to start hunting this phantom error down.
Looks like it's going to be a lost week!
Best,
Laird
