Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi, Unfortunately, it's not going to be near future. It's definitely not 2.7 (which was frozen a long time ago), almost definitely not 2.8 (because it would probably take to much time to do and 2.8 is supposed to figure out other stuff related to Java 9+ support). You can always workaround this

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi, We are also facing this issue while trying to retrieve domain objects inside a compute task. Do you have plans to add this feature in the near future? maybe 2.7 release? regards -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

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

Is there any update on the suggested functionality to resolve cache entry classes based on the caller's context first instead of relying on Ignite's classloader? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

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

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Crosspost to dev list. Igniters, This proposal looks quite reasonable. Do we have any restrictions that could prevent implementing such feature? I think it's nice to have in Ignite. Thanks! -Dmitry. On Sun, Apr 23, 2017 at 1:37 AM, npordash wrote: > Thanks! > > That

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Thanks! That would definitely help address the hack I've implemented where I have to reference classes in Ignite's internal package. However, I still have to work with the caches in binary which is less than ideal. It's pretty common in use-cases like this to first try to use

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi Nick, Unfortunately there is no way to use custom class loader without hacks with internal API. I've opened a ticket for this feature [1], it could be useful in such cases, please check. [1] https://issues.apache.org/jira/browse/IGNITE-5038 Thanks! -Dmitry. 19.04.2017 20:09, npordash

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

Thanks, Dmitry! This is using Ignite 1.9. The stack trace is pretty straight forward: Putting things into caches works just fine (f.e. instances of that Namespace class), but pulling them out does not since the cache is only taking Ignite's classloader into account. For the time being I've had

BinaryObjectImpl.deserializeValue with specific ClassLoader

Hi, I have a use-case where I'm deploying services to the grid where the service implementation that's deployed to all ignite data nodes is really just a skeleton that downloads implementation jar files from IGFS and initializes the "real" service using a URLClassLoader (similar to what Storm,