ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From npordash <nickpord...@gmail.com>
Subject Re: BinaryObjectImpl.deserializeValue with specific ClassLoader
Date Sat, 22 Apr 2017 22:37:41 GMT

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
Thread.currentThread().getContextClassLoader() and if that's not set then
fallback to something else. In general, I think ignite should try to resolve
a class based on the caller's context first instead of only relying on
ignite's classloader or what it was configured with.

In the spirit of the webinar that Denis just had, I think this kind of
behavior will become mandatory for the service grid to get to the point
where it can do deployments of services without requiring class files to be
on ignite's classpath. I've heard that is something that's still tentatively
planned and the use-case I outlined is an attempt to get around the current
service grid limitations. :)



View this message in context: http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp12055p12171.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message