As discussed on http://openjpa.markmail.org/search/?q=#query:list%3Aorg.apache.openjpa.users+page:1+mid:yua5kf7vd5m7wrnw+state:results, there is a bug in OpenJPA iff ... "any @Id field of a composite key mapped via an @IdClass identity is NULL" (enough keywords to allow future searching? .
The attached test case provides running code illustrating this with two simple entities and a failing JUnit.
While relational database do NOT appear to allow NULL value for columns which are part of a PRIMARY KEY CONSTRAINT, this kind of situation and mapping can (and in our case has!) occurred when mapping to legacy schemas with tables where a certain number / subset of columns are in fact the "logical" identifying set, without there being a physical PK constraint (nothing says you HAVE to have a physical PK). – Both JPA Spec and OpenJPA doc make no statement if this is supposed to work or not work, they say nothing about this (as far as I could see; I checked before filing this; and nobody on the list made any statements re. this). It would be interesting to know if and how other JPA implementations handle this.
Assuming this is a small internal implementation bug and not a conceptual / design issue (note it's NOT the @IdClass instance that is null, it's only some fields within an Id, with others being available; and uniqueness of the combination guaranteed by data in DB of course!), it would be great if this could be make to work as one would naturally expect. (Or, at the very least, OpenJPA should fail and issue a clear error message, instead of just returning null; fix much better though.)