I have two custom datatypes: A and B where B extends A.
Also I do have AAttributeConverter for A and BAttributeConverter for B (both with @Converter(autoApply = true)).
This scenario works fine with hibernate 5.0.9.Final.
However, when I update to recent 5.2.8.Final I get this error:
The property MyBean.value has type B that extends A. As BAttributeConverter is more specific and AAttributeConverter can not actually handle B hibernate should IMHO not consider AAttributeConverter here.
I agree but this used to work before. We so far could not update to a newer version of hibernate. Now we figured other bugs such that force us to update. Finally we are locked out by hibernate as there is no constellation left that works for our app. Changing things in an incompatible manner is always a tricky impact. I am happy that Hibernate is actively doing cleanups and refactorings to remain future proof. However, such problems can turn out as blockers for your users and if they then are lowest prio as this is unspecified it gets tricky to proceed. Any hints or workarounds are highly appreciated.
While I understand the desire to label this a regression, it is not. A regression by definition must change a documented behavior. Can you point me to the documentation that explains the previous behavior? If not, this is a REF as I already stated.
In case it helps. I analyzes that the breaking change was introduced due to with
If the intention was only to fix (AttributeConverter should supports ParameterizedType if autoApply is true) then there is actually no reason why the previous behavior of assigning polymorphic converters had to be changed/broken.
> A regression by definition must change a documented behavior. Can you point me to the documentation that explains the previous behavior?
Nope. If that is your definition of regression then this is no regression by definition - however the term is used with other definitions outside hibernate. I do not want to fight for words here. As long as we agree that a fix of this problem (add this to the documentation and then implement accordingly) would be valuable (no matter what priority) then we come to an agreement. If so I might even look for a suggestion to a fix or even try a PR but as I am heavily involved in many OSS projects I can not guarantee anything. Spare time is raw as you will know...
We will agree to disagree about the definition of regression, ut I do agree the current behavior you defined is wonky and should be fixed and properly documented - although given your definition of regression I guess the documentation change is unnecessary
Thanks for taking the time to investigate
This worked in 5.0.12 as well. I don't see a way to enter that info when editing the issue.