Crosspost to dev list. Igniters,
This proposal looks quite reasonable. Do we have any restrictions that could prevent implementing such feature? I think it's nice to have in Ignite. Thanks! -Dmitry. On Sun, Apr 23, 2017 at 1:37 AM, npordash <nickpord...@gmail.com> wrote: > 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. >
