[ 
https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029998#comment-16029998
 ] 

Nick Pordash commented on IGNITE-5038:
--------------------------------------

Thanks [~v.pyatkov]!

There are really two changes that can be deduced from the dev list discussion:

1) What your PR currently contains
2) Defaulting to Thread.currentThread().getContextClassLoader() in the no-args 
deserialize methods and if that is null then fallback to the classloader in 
IgniteConfiguration

#1 gives fine-grained control over what classloader is used, which is good 
since I don't have to fallback on internal Ignite APIs and also the 
deserialized value is properly cached by BinaryObjectImpl.

#2 is about having less surprising behavior when it comes to automatically 
determining which classloader to use. Without this I still have to work with 
caches in binary which means if I want to provide a better development 
experience (f.e. allow working with POJOs) I need to expose custom Ignite and 
IgniteCache implementations in my APIs so that I can do this classloader 
detection myself.

I'm not sure if this should really be two separate issues/PRs or not or if more 
discussion is needed around #2.

> BinaryMarshaller might need to use context class loader for deserialization
> ---------------------------------------------------------------------------
>
>                 Key: IGNITE-5038
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5038
>             Project: Ignite
>          Issue Type: New Feature
>          Components: cache
>    Affects Versions: 2.0
>            Reporter: Dmitry Karachentsev
>            Assignee: Vladislav Pyatkov
>              Labels: features
>             Fix For: 2.1
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to