With this composite key, somehow a org.hibernate.proxy.pojo.javassist.SerializableProxy makes it in as part of the CacheKey. That then fails on deserialization.
I don't know whether this mapping is to be addressed with a UserType or not, but if it would be, the disassemble method would be a potential place to address this leak. The whole object graph doesn't need to be used as a Key, a struct of PK of the composite would achieve the same semantics (probably actually a more correct one).
The Ehcache RegionFactory, iirc the discussion I had with Sanne, do exactly what Hibernate used to do prior the 5.0 refactoring. Anyways, best would be to have a complete reproducible test case and see from there.
My theory right now is, the CacheKey contains the ModelOrderColor instance (as part of that PicturePK class instance and as this extends BaseEntity which implements Serializable) and that leaks the `org.hibernate.proxy.pojo.javassist.SerializableProxy` somehow. What I would have done (back in the 3.x days) would have been to disassemble that PicturePK to something much "smaller" (i.e. an array of the pk) rather than having this huge PK object graph get in the `Cache`. Hence me mentioning the `UserType`.