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 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. :) WDYT? -Nick -- 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.
