HHH-8851: composite ids via hbm.xml cause 'expected IdClass mapping': any fix/workaround?


#1

Is there any fix or workaround (short of completely re-writing code) to get <composite-id> to work with hbm.xml? See HHH-8851 for an explanation of how this is currently broken

======== Additional background =======
We have a very large legacy application (over 200 Java ‘projects’ mostly developed about a decade ago) and are in the laborious process of upgrading it from Hibernate 3 to 5. The intent with this release is to perform the minimum changes necessary for the framework upgrade, then subsequently complete more complex code revisions to the code base in later releases of the application.

One of the problems we encountered was that Hibernate 5 (we are currently targeting 5.3.3.Final) requires any use of <composite-id> to specify the class used. Updating the XML to provide identify the class subsequently results in an error of the form:
java.lang.IllegalArgumentException: expecting IdClass mapping

Digging through error reports, I find that this is a currently unresolved bug known since approximately a year ago and documented (somewhat unclearly) under HHH-8851. There is also a forum thread (old forums) related to HHH-8851, but since I’m a new user I can’t add it as a link=> https://forum.hibernate.org/viewtopic.php?f=1&t=1030434


#2

Maybe it got fixed by HHH-12550. Did you try it with 5.3.3?

Digging through error reports, I find that this is a currently unresolved bug known since approximately a year ago and documented (somewhat unclearly) under HHH-8851 1.

HBM mappings are considered deprecated, and will probably be removed in a future version of Hibernate. On the long-run, migrating to JPA annotations or XML mappings is the way to go. If you can replicate the issue, the fastest way to have it fixed and released is to send us a Pull Request with a possible fix for it. Otherwise, I don;t think this issue is really a priority for the moment, and due to lack of resources, it might be postponed even longer.


#3

HHH-12550 is ‘resolved=> duplicate’ i.e.: nothing was resolved, it was just closed as a duplicate of HHH-8851. I find that work item notation to be rather confusing, but there is no evidence of anything being delivered to fix it so that’s my interpretation. And we are using release 5.3.3 so the problem definitely appears to still exist in that release.

Re: submitting a pull request; I think submitting proposed changes to the Hibernate framework is beyond our project’s resourcing at the moment. If our application’s code was more up to date, I’d feel better re: our capacity to build rational test cases. A bit of a catch-22, indeed.

Re: HBM mappings being deprecated- understood. If the problem had been fixed, or if there was an ‘easy’ work around that didn’t involve too many code changes, it would have been a good thing for us. That not being the case means we’ll have to figure out what we can afford to change in our application to accommodate the deficiency.


#4

The workaround is very easy. You can use annotations for this class or even for the ID declaration without having to rewrite everything to annotations.

Just make sure that annotations take precedence over HBM, as by default, is the other way around. You can control that with the scanning order property.


#5

Ah, Vlad: the fact that we can mix annotations and HBM in our legacy application is a critical piece of information- Thank you!

Can you refer me to any guidance on the scanning order settings?


#6

Take a look at the metadata configurations.