There is definitely an issue here. The code in HEM is just wrong. I am not familiar enough with the code/spec here in regards to static metamodel generation to determine the appropriate fix on my own. The model in question there is essentially: @MappedSuperclass abstract class AbstractAttribute { protected String key; protected String value; public abstract String getOwner(); @Column(name = "attribute_key") public String getKey() { return key; } @Column(name = "attribute_value") public String getValue() { return value; } // setters } then we have: @Entity public class ProductAttribute extends AbstractAttribute { private String owner; @Id @Column(name = "owner") public String getOwner() { return owner; } @Id @Column(name = "attribute_key") public String getKey() { return key; } // setters } The attributes in question are the 2 (key,owner) that get overridden in the subclass. We end up with a mismatch. The metamodel generator does: @StaticMetamodel(AbstractAttribute.class) public abstract class AbstractAttribute_ { public static volatile SingularAttribute<AbstractAttribute, Integer> owner; public static volatile SingularAttribute<AbstractAttribute, String> value; public static volatile SingularAttribute<AbstractAttribute, String> key; } @StaticMetamodel(ProductAttribute.class) public abstract class ProductAttribute_ extends AbstractAttribute_ { } In the type system however only value shows up as "declared" by AbstractAttribute. These other 2 show up as being declared by ProductAttribute, presumably because that is where there ultimate metadata is defined. I think the metamodel is defined correctly, but then that leaves a question as to how we handle that for the type system (org.hibernate.mapping.MappedSuperclass).

I also got a working test case now using EmbeddedId as well. See tests in * hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/embeddedid * hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/idclass On Mon 09 Jan 2012 03:47:40 PM CST, Steve Ebersole wrote: > I should point out... this *only* fails when the entity > (ProductAttribute) is annotated with an @IdClass > > On Mon 09 Jan 2012 03:06:51 PM CST, Steve Ebersole wrote: >> There is definitely an issue here. The code in HEM is just wrong. I >> am not familiar enough with the code/spec here in regards to static >> metamodel generation to determine the appropriate fix on my own. >> >> The model in question there is essentially: >> >> @MappedSuperclass >> abstract class AbstractAttribute { >> protected String key; >> protected String value; >> >> public abstract String getOwner(); >> >> @Column(name = "attribute_key") >> public String getKey() { return key; } >> >> @Column(name = "attribute_value") >> public String getValue() { return value; } >> >> // setters >> } >> >> then we have: >> >> @Entity >> public class ProductAttribute extends AbstractAttribute { >> private String owner; >> >> @Id @Column(name = "owner") >> public String getOwner() { return owner; } >> >> @Id @Column(name = "attribute_key") >> public String getKey() { return key; } >> >> // setters >> } >> >> The attributes in question are the 2 (key,owner) that get overridden >> in the subclass. We end up with a mismatch. >> >> The metamodel generator does: >> >> @StaticMetamodel(AbstractAttribute.class) >> public abstract class AbstractAttribute_ { >> >> public static volatile SingularAttribute<AbstractAttribute, Integer> >> owner; >> public static volatile SingularAttribute<AbstractAttribute, String> >> value; >> public static volatile SingularAttribute<AbstractAttribute, String> >> key; >> } >> >> @StaticMetamodel(ProductAttribute.class) >> public abstract class ProductAttribute_ extends AbstractAttribute_ { >> } >> >> In the type system however only value shows up as "declared" by >> AbstractAttribute. These other 2 show up as being declared by >> ProductAttribute, presumably because that is where there ultimate >> metadata is defined. >> >> I think the metamodel is defined correctly, but then that leaves a >> question as to how we handle that for the type system >> (org.hibernate.mapping.MappedSuperclass). >> >