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.
>

Reply via email to