Nick,
Internally, binary marshaller supports as many class loaders as needed. Even
more, it can store different versions of the same class loaded by different
loaders. It’s a responsibility of an Ignite component to pass a valid class
loader to it at deserialization time.
The cache component simply passes IgniteConfiguration.getClassLoader() all the
times. If that class loader is not, meaning the marshaller will received ’null’
as a class loader value then it will use the system class loader.
Here is on of the places in the caching internals that triggers an object
deserialization
private BinaryReaderExImpl reader(@Nullable BinaryReaderHandles rCtx, boolean
forUnmarshal) {
BinaryOffheapInputStream stream = new BinaryOffheapInputStream(ptr, size,
false);
stream.position(start);
return new BinaryReaderExImpl(ctx,
stream,
ctx.configuration().getClassLoader(),
rCtx,
forUnmarshal);
As an idea, what if you create your custom class loader that will offload to a
context class loader whenever is needed. Do you think it will work for you?
—
Denis
> On Apr 25, 2017, at 4:23 PM, npordash <nickpord...@gmail.com> wrote:
>
> 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.
