Hi guys,
Cache entries don’t store an identification of the class loader a key or value was created with. This is why binary marshaller picks the system class loader at deserialization time by default and you get class not found exception. >> 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. That’s probably worth looking into but for the cache entries we tried to simplify the things - if you want to deserialize an entry then most likely you’re doing this on the app side that already has the class in the class path. For the server nodes, that usually doesn’t have the classes it’s suggest to use BinaryObject and BinaryObjectBuilder wrappers on top of serialized data: https://apacheignite.readme.io/docs/binary-marshaller#binaryobject-cache-api Vovan, what do you think on this? — Denis > On Apr 24, 2017, at 12:55 AM, Dmitriy Karachentsev > <dkarachent...@gridgain.com> wrote: > > 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. >>
