[
https://issues.apache.org/jira/browse/IGNITE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233424#comment-15233424
]
Denis Magda commented on IGNITE-2947:
-------------------------------------
Anton, I have an idea how all this stuff can be fixed once and for all the
cases (default loader, configuration loader, deployment loaders). This can be
done at the level of {{MarshallerContextAdapter}} and after that we should be
able to get rid off {{BinaryContext.userTypes}} map at all.
Presently {{MarshallerContextAdapter.registerClass()}} doesn't put
"typeId"->"clsName" mapping to local node map if the registration failed at the
cache level. We can always put the mapping ("clsName",registered) to that map
in {{MarshallerContextAdapter}}. After that
{{MarshallerContextAdapter.getClass(typeId)}} will always return a class even
in tests like {{GridBinaryMarshallerCtxDisabledSelfTest}}. When
{{MarshallerContextAdapter.registerClass()}} is called the next time it will
check "registered" flag in addition registering the mapping if it has not been
done before.
At the level of {{BinaryContext}} we can use Alexe's suggestion plus remove
rudimental "userTypes" map. However after removing "userTypes" map we should
run the benchmarks.
> BinaryContext doesn't honor custom loader set through
> IgniteConfiguration.classLoader
> -------------------------------------------------------------------------------------
>
> Key: IGNITE-2947
> URL: https://issues.apache.org/jira/browse/IGNITE-2947
> Project: Ignite
> Issue Type: Bug
> Components: binary
> Affects Versions: 1.5.0.final
> Reporter: Denis Magda
> Assignee: Anton Vinogradov
> Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> If to register a specific object with {{BinaryTypeConfiguration}} setting its
> {{typeName}} and load Class of objects of this type using a custom class
> loader passed to {{IgniteConfiguration.classLoader}} then at
> {{BinaryContext}} initialization time the context will not properly register
> this {{BinaryTypeConfiguration}} because it doesn't suppose that the Class of
> the type can be loaded by the custom class loader
> In the code below {{Class.forName}} has to use
> {{IgniteConfiguration.classLoader}} if the latest is set and fall back to
> {{dfltLdr}} otherwise.
> {noformat}
> @SuppressWarnings("ErrorNotRethrown")
> public void registerUserType(String clsName,
> BinaryInternalMapper mapper,
> @Nullable BinarySerializer serializer,
> @Nullable String affKeyFieldName,
> boolean isEnum)
> throws BinaryObjectException {
> assert mapper != null;
> Class<?> cls = null;
> try {
> cls = Class.forName(clsName);
> }
> catch (ClassNotFoundException | NoClassDefFoundError ignored) {
> // No-op.
> }
> {noformat}
> Also there are several conditions in {{BinaryContext}} that are done for
> {{dfltLdr}}. The same conditions have to be executed for
> {{IgniteConfiguration.classLoader}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
