Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

The ticket is on the radar, but not in immediate plans. The problem might sounds simple at first glance, but we already spent considerable time on implementation and review, because we heavily rely on classes caching, and a lot of internal BinaryMarshaller infrastructure should be reworked to

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Ticket is still open. Vladimir, looks like it's assigned to you. Do you have any plans to work on it? https://issues.apache.org/jira/browse/IGNITE-5038 -Val On Wed, Jan 3, 2018 at 1:26 PM, Abeneazer Chafamo wrote: > Is there any update on the suggested

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi Nick, How exactly do you replace the class loader and can you give a little bit more detail about why you do this? As for the issues, here are my comments: 1. Can you clarify this? In which scenario it doesn't work and why? 2. Why do you deploy domain classes in the first place? Ignite

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

I wanted to provide an update on where I am at with this as I'm still exploring different options. For the time being I've taken the path of using a delegating ClassLoader in IgniteConfiguration as was previously suggested; however, with the difference being that whenever a service is

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Thanks Denis! -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p17524.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hey Denis, I tried your solution as that is what Alexei was more-or-less suggesting: create a delegating classloader, but in this case delegate to whatever context class loader is set. The problem is that resolved classes will always be stored by the instantiated classloader, which would be the

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Nick, Internally, binary marshaller supports as many class loaders as needed. Even more, it can store different versions of the same class loaded by different loaders. It’s a responsibility of an Ignite component to pass a valid class loader to it at deserialization time. The cache component

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Nick, Have you tried implementing delegating classloader and set it using IgniteConfiguration.setClassLoader() ? This should solve your problem without any API changes on Ignite's side. 2017-04-25 22:42 GMT+03:00 npordash : > Hi Denis, Val, > > Please refer to my initial

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi Denis, Val, Please refer to my initial inquiry on the user forum for full context as I think that was lost while cross-posting to here: http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td12055.html The setting in IgniteConfiguration

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

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 > wrote: > > We allow to provide custom class loader via >

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

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 wrote: > Nick, > > This deserialization issue

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

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

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

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

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi guys, Cache entries don’t store an identification of the class loader a key or value was created with. This is why binary marshaller picks the system class loader at deserialization time by default and you get class not found exception. >> In general, I think ignite should try to resolve a