I am getting NPE while reading revisions of entity with @EmbeddedId composite key located in parent @MappedSuperclass.
Minimalistic reproducible sample is located here: https://github.com/pmihalcin/envers-audit-reader-npe-composite-key
First commit adds working example.
Second commit moves composite key to parent @MappedSuperclass and test case: https://github.com/pmihalcin/envers-audit-reader-npe-composite-key/blob/master/src/test/java/com/example/enverstest/TriggerRepositoryTest.java starts failing on NPE.
JVM - 1.8, Ubuntu, H2 locally, hibernate 5.0.12, hibernate 5.3.10
The reason the NPE happens is we’re doing some reflection at runtime to instantiate TriggerPK inside the call of EmbeddedIdMapper#mapToEntityFromMap when we hydrate the dynamic-map data stored for the audit structure into the actual java class type. With how you’re using generics, the code presently sees the identifier’s return type as Serializable rather than TriggerPK since the super-type actually technically defines it as such. Since Serializable is abstract, this leads to the NPE.
A quick workaround would be to actually override the getter in your model inside Trigger as such:
That should suffice to trick the EmbeddedIdMapper to properly result the return-type of the identifier so that it actually returns TriggerPK rather than Serializable, avoiding the NPE.
In the meantime, I’ll look at the code and see if I can find a resolution.
I’ve opened PR .
Once CI passes, I’ll merge this into master (currently 5.4) for the next release.
Hi Chris.. thanks a lot for the explanation and the fix!
Will you also backport this fix into 5.0.x version?
Hi , unfortunately likely not. The last release for 5.0.x was 2017 and is no longer being maintained by the community at this point. I think the oldest branch we could see this being ported back to most likely is 5.3.x. , wdyt?
, it's not critical or a regression, and it has a workaround, so I don't think it should be backported to 5.3.