We allow to provide custom class loader via IgniteConfiguration.setClassLoader. If this class loader is ignored during deserialization of cache objects, then I believe it's a bug.
-Val On Tue, Apr 25, 2017 at 7:36 PM, Denis Magda <dma...@apache.org> wrote: > Nick, > > This deserialization issue is related to cache objects. You will get the > same kind of exception if you try to deserialize a cache entry inside of a > compute task which class was preloaded using the peer-class-loading feature. > > Frankly, this is not treated as an issue on Ignite side. We designed cache > objects serialization/deserialization in a way it works now - the class has > to be in the local classpath. > > However, probably it makes sense to rethink this. *Val*, *Vovan*, what are > your thoughts on this? > > — > Denis > > > On Apr 24, 2017, at 6:06 PM, npordash <nickpord...@gmail.com> wrote: > > > > Hi Denis, > > > >>> if you want to deserialize an entry then most likely you’re doing this > on > >>> the app side that already has the class in the class path > > > > In this particular case the app is a deployed service and the hosting > node > > doesn't have the class files on its classpath. I implemented a way to > deploy > > and run services on the grid even if the class files are not known by > ignite > > (which is current service grid limitation). It works fine except for this > > deserialization issue. > > > > -Nick > > > > > > > > -- > > View this message in context: http://apache-ignite- > developers.2346864.n4.nabble.com/Re-BinaryObjectImpl- > deserializeValue-with-specific-ClassLoader-tp17126p17173.html > > Sent from the Apache Ignite Developers mailing list archive at > Nabble.com. > >
