Nick, Looks like we need to look into it, thanks for extensive explanation and your time. I’ve updated the originally created ticket: https://issues.apache.org/jira/browse/IGNITE-5038
Feel free to expand the description if needed. — Denis > On Apr 28, 2017, at 4:35 PM, npordash <nickpord...@gmail.com> wrote: > > Hey Denis, > > I tried your solution as that is what Alexei was more-or-less suggesting: > create a delegating classloader, but in this case delegate to whatever > context class loader is set. The problem is that resolved classes will > always be stored by the instantiated classloader, which would be the > delegating one here, and there is no way around that from what I can tell. > There is a fair amount of native code involved and I'm not sure exactly > what's going on there (f.e. Class.forName eventually calls Class.forName0 > which is native and ClassLoader.loadClass eventually calls > ClassLoader.resolveClass0 which is also native). > > I ran a test to prove out the above where I created a dynamic class using > ByteBuddy and the following happened: > 1) Create URLClassLoader and successfully loaded the class there > 2) Attempted to resolve the class using the system classloader (failed as > expected) > 3) Created a delegating classloader and attempted to resolve (failed as > expected) > 4) Set the context classloader to the urlclassloader and attempted to > resolve (worked as expected) > 5) Restored the context classloader to the system classloader and attempted > to resolve (worked which I was hoping it didn't do). > > Regarding your code snippet - I did see that and was wondering if it could > do something like the following instead: > > > > I believe getContextClassLoader by default doesn't return null anymore > (since after Java 1.4 or something I believe?) but it is still technically > possible. > > I think at least when running sql queries or getting data out of a cache it > is probably a safe assumption that if the calling thread wants to > deserialize as a class called Foo then that class is probably already > available via the context classloader and that takes the burden off of > Ignite on trying to "do the right thing" about class resolution. > > -Nick > > > > -- > View this message in context: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-tp17126p17339.html > Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
