[
https://issues.apache.org/jira/browse/HBASE-26014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Lopukhov updated HBASE-26014:
------------------------------------
Description:
Classes which uses ServiceLoader facility does not specify ClassLoader to use.
For hbase-client 2.4.1 they are (at least):
* SaslClientAuthenticationProviders
* MetricRegistries
When hbase libraries are loaded dynamically and Thread Context Classloader is
not set SaslClientAuthenticationProviders instantiation failes becuse it can't
find default providers.
Some proposals for classloader selection strategy (usage dependent I guess):
* Use classloader specified in Configuration instance.
* Use classloader which loaded specific hbase class
* Combine them: use classloader from Configuration if present and fallback to
classloader which loaded specific hbase class
Real world requirement example: currently we migrating from hbase 1 to hbase 2.
For better compatibility and smooth migration we try to build abstraction
around hbase client libraries and isolate them with custom classloaders. To
workaround problems with context classloader we must either wrap all calls to
use proper contextclassloader or explicitly trigger initialization of affected
classes (SaslClientAuthenticationProviders) wich are marked private under
proper context classloader. It would be better if hbase client will take care
of it itself.
was:
Classes which uses ServiceLoader facility does not specify ClassLoader to use.
For hbase-client 2.4.1 they are (at least):
* SaslClientAuthenticationProviders
* MetricRegistries
When hbase libraries are loaded dynamically and Thread Context Classloader is
not set SaslClientAuthenticationProviders instantiation failes becuse it can't
find default providers.
Some proposals for classloader selection strategy (usage dependent I guess):
* Use classloader specified in Configuration instance.
* Use classloader which loaded specific hbase class
* Combine them: use classloader from Configuration if present and fallback to
classloader which loaded specific hbase class
Real world example: currently we migrating from hbase 1 to hbase 2. For better
compatibility and smooth migration we try to build abstraction around hbase
client libraries and isolate them with custom classloaders.
> ServiceLoader usages are tied to Thread Context Classloader
> -----------------------------------------------------------
>
> Key: HBASE-26014
> URL: https://issues.apache.org/jira/browse/HBASE-26014
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrei Lopukhov
> Priority: Major
>
> Classes which uses ServiceLoader facility does not specify ClassLoader to use.
> For hbase-client 2.4.1 they are (at least):
> * SaslClientAuthenticationProviders
> * MetricRegistries
> When hbase libraries are loaded dynamically and Thread Context Classloader is
> not set SaslClientAuthenticationProviders instantiation failes becuse it
> can't find default providers.
> Some proposals for classloader selection strategy (usage dependent I guess):
> * Use classloader specified in Configuration instance.
> * Use classloader which loaded specific hbase class
> * Combine them: use classloader from Configuration if present and fallback
> to classloader which loaded specific hbase class
> Real world requirement example: currently we migrating from hbase 1 to hbase
> 2. For better compatibility and smooth migration we try to build abstraction
> around hbase client libraries and isolate them with custom classloaders. To
> workaround problems with context classloader we must either wrap all calls to
> use proper contextclassloader or explicitly trigger initialization of
> affected classes (SaslClientAuthenticationProviders) wich are marked private
> under proper context classloader. It would be better if hbase client will
> take care of it itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
