Hi Alexei, I believe the problem with that approach is that I won't be able to reload classes because there is a single classloader that Ignite is referencing. When I undeploy a service I also want to allow the corresponding classloader (there is 1 per service) and classes to get reclaimed by the JVM (if it choses to do so, of course).
It would also prevent multiple versions of the same class from being used. If I have two services deployed then I don't want classes from service 1 to get resolved by service 2 simply because service 1 was there first and a class with the same name was already resolved by the delegating classloader. It's entirely possible the version of the class files are different and this would lead to some interesting and confusing errors. This is why I was suggesting to refer to the thread context classloader during deserialization because it doesn't impact your API and it addresses all of the above issues. However, I can't get a feel for the behavioral impact of this change by simply looking at the Ignite codebase and I'm not sure what the rationale was to restrict classloading to Ignite's classloader. -Nick -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p17224.html Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
