It doesn't look like a classpath issue but rather an issue with class loading. Since the app is a self-contained unit and multiple apps can be launched from a single apex cli session, apex uses a separate classloader for each app and provides this classloader to kryo to instantiate the classes during deserialization from prior state, kryo is using this classloader for the most part but when part of the deserialization is being handed off to java, java is not using the same classloader and hence is failing to find the class. This is not the best method but you can create a custom java serializer by copying the kryo's JavaSerializer class code but in the read method where it is creating an ObjectInputStream (line 42), create a class that extends ObjectInputStream and overrides resolveClass method to return a class using the current thread's classloader which can be obtained by making a call to Thread.currentThread().getContextClassLoader().
Thanks On Thu, Aug 10, 2017 at 2:47 PM, Vivek Bhide <vivek.bh...@target.com> wrote: > I have already pasted the stack trace in my original post. Also can you > please confirm what is the classpath kryo is using v/s default Java > serializer and where exactly is set for kryo? > > Regards > Vivek > > > > -- > View this message in context: http://apache-apex-users-list. > 78494.x6.nabble.com/How-the-application-recovery-works- > when-its-started-with-originalAppId-tp1821p1827.html > Sent from the Apache Apex Users list mailing list archive at Nabble.com. >
