It’s a good point. Thanks for reminding Val. Nick, please check that the suggested method works for your use case.
— Denis > On Apr 25, 2017, at 11:16 AM, Valentin Kulichenko > <valentin.kuliche...@gmail.com> wrote: > > 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. >> >>
