2.8.7 NoSuchMethodError PersistentCollection.setCurrentSession

[coladict]

They changed the signature of the method in 5.2 and now instead of SessionImplementor it takes SharedSessionContractImplementor.

This fixed it.

diff --git a/hibernate5/src/main/java/com/fasterxml/jackson/datatype/hibernate5/PersistentCollectionSerializer.java b/hibernate5/src/main/java/com/fasterxml/jackson/datatype/hibernate5/PersistentCollectionSerializer.java
index 140d8b3..392eb31 100644
--- a/hibernate5/src/main/java/com/fasterxml/jackson/datatype/hibernate5/PersistentCollectionSerializer.java
+++ b/hibernate5/src/main/java/com/fasterxml/jackson/datatype/hibernate5/PersistentCollectionSerializer.java
@@ -21,6 +21,7 @@ import com.fasterxml.jackson.databind.ser.ContextualSerializer;
 import com.fasterxml.jackson.databind.ser.ResolvableSerializer;
 import com.fasterxml.jackson.databind.util.NameTransformer;
 import com.fasterxml.jackson.datatype.hibernate5.Hibernate5Module.Feature;
+import java.lang.reflect.InvocationTargetException;
 
 import org.hibernate.FlushMode;
 import org.hibernate.Hibernate;
@@ -63,6 +64,8 @@ public class PersistentCollectionSerializer
 
     protected final SessionFactory _sessionFactory;
 
+    protected final Method _collectionSessionInitMethod;
+
     /*
     /**********************************************************************
     /* Life cycle
@@ -77,6 +80,7 @@ public class PersistentCollectionSerializer
         _serializer = (JsonSerializer<Object>) serializer;
         _features = features;
         _sessionFactory = sessionFactory;
+        _collectionSessionInitMethod = initCollMetod();
     }
 
     /**
@@ -90,6 +94,22 @@ public class PersistentCollectionSerializer
         _serializer = (JsonSerializer<Object>) serializer;
         _features = base._features;
         _sessionFactory = base._sessionFactory;
+        _collectionSessionInitMethod = initCollMetod();
+    }
+
+    protected Method initCollMetod() {
+        try {
+            Class<?> cl = SessionFactory.class.getClassLoader().loadClass("org.hibernate.collection.spi.PersistentCollection");
+            for (Method m : cl.getMethods()) {
+                if (m.getName().equals("setCurrentSession")) {
+                    return m;
+                }
+            }
+        }
+        catch (ClassNotFoundException ex) {
+            throw new IllegalStateException("Hibernate version is incompatible for lazy collection serialization", ex);
+        }
+        throw new IllegalStateException("Hibernate version is incompatible for lazy collection serialization");
     }
 
     @Override
@@ -348,7 +368,13 @@ public class PersistentCollectionSerializer
             session.beginTransaction();
         }
 
-        coll.setCurrentSession(((SessionImplementor) session));
+        try {
+            _collectionSessionInitMethod.invoke(coll, session);
+        }
+        catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException ex) {
+            throw new IllegalStateException("Hibernate version is incompatible for lazy collection serialization", ex);
+        }
+
         Hibernate.initialize(coll);
 
         if (!isJTA) {

If you migrated to Gradle you could actually test different provider versions in the same build. For example, I managed to do it like this https://github.com/mopano/hibernate-json-type/blob/d25edecea9cab619207e4888c850c96bc65f10ea/build.gradle

Lines 28-32 define configurations for each provider; Lines 50-52 define dependency for each configuration; Lines 62-81 define new test tasks for each provider configuration. Lines 66, 73, 80 set classpaths for each task accordingly.

That's the kind of flexibility Maven will never provide.

With this patch it managed to serialize my object that was crashing after it had just been persisted.

[cowtowncoder]

So, just to make sure I understand: is this a proposed patch to fix another problem? And one that still occurs with 2.8.7, not fixed with #102? There is sub-module, hibernate5_2-test, that was contributed and should be able to test against 5.2 (and similar technique should allow other testing), although I am not sure right now it functions as intended. But it would seem like it should be able to cover this, without having to resort to conversion to other build system (and one I've never used nor have plans to use).

[coladict]

It is another problem, yes. I could not find my old logs for the first problem and how to recreate it. It seems the other problem merely prevented us from getting to this one.

[cowtowncoder]

@coladict Ok. Very unfortunate that supposed patch only pushed bottleneck bit further then.

[coladict]

It turns out in 5.1 the Session not yet an EntityManager, so the isJta fix for 5.2 actually breaks 5.1. There just isn't a way to do it without version checks.

I've made a test for it http://pastebin.com/6ZuLgNS9 but I can't spare more time right now to make it work in both cases.

[cowtowncoder]

@coladict ugh. That's even worse then... It is possible to have different module altogether, if need be. But form user perspective that wouldn't be particularly good thing.

[coladict]

You could have one class handle 5.1 and another 5.2 and just load the appropriate object on initialization. Of course, either one or both would have to use reflection for that, depending on what you compile against.

[sayan-mitra]

@coladict though I raised #106 , any workaround to this? Being new to Hibernate, I am in a fix.