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 deployed/undeployed I end up replacing the ClassLoader with a new instance that has the service's ClassLoader added/removed. The replacement is necessary so that unused/old classes can be reclaimed by the garbage collector and that new versions can be deployed in the future. Overall I think this is a more comprehensive approach since it also allows execution constructs like CacheEntryProcessor implementations provided by the service to be used across the grid without enabling p2p classloading (assuming the service is deployed to every node). There are a few concerns/issues with this approach: 1) There are still isolation concerns with class versions across different services, but as long as the services don't have dependencies between each other or have overlapping class usage in a cache or execution context then it's a non-issue. 2) Using OnheapCacheEnabled in conjunction with service provided domain classes is impossible since once the service is reloaded and we get a new classloader all calls to deserialize will fail. 3) This approach only works if nothing caches the result of IgniteConfiguration.getClassLoader, which isn't obvious since the docs related to classloader behavior in Ignite is pretty sparse (or at least I could not find it). I don't think anything does when I check that method usage, but I'm not 100% sure about that. -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p18358.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
