Francis Liu commented on HBASE-19920:

[~mdrob] Rohini and I were talking about this last friday. As far as I can tell 
DynamicClassLoader is mainly for supporting custom filters tho there are some 
other cases (eg custom comparator for checkAndPut).

In any case, it sounds reasonable to assume that if a client (not running in 
regionserver, master, etc) needs to use a custom filter/coprocessor/etc it 
would have direct access to the classes (ie in classpath) to use the apis. So 
it would seem reasonable to assume that we only need to enable 
DynamicClassLoader on clients running in an HBase daemon?

Having said that the approach you've currently taken sounds fine as it 
addresses the immediate concern. Tho a bit tricky as future code changes may 
make use of ProtobufUtil (sounds like we need to add an IT test to avoid 

> TokenUtil.obtainToken unnecessarily creates a local directory
> -------------------------------------------------------------
>                 Key: HBASE-19920
>                 URL: https://issues.apache.org/jira/browse/HBASE-19920
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Rohini Palaniswamy
>            Assignee: Mike Drob
>            Priority: Major
>             Fix For: 2.0
>         Attachments: HBASE-19920.patch
> On client code, when one calls TokenUtil.obtainToken it loads ProtobufUtil 
> which in its static block initializes DynamicClassLoader and that creates the 
> directory ${hbase.local.dir}/jars/ and also instantiates a filesystem class 
> to access hbase.dynamic.jars.dir.
> https://github.com/apache/hbase/blob/master/hbase-common/src/main/java/org/apache/hadoop/hbase/util/DynamicClassLoader.java#L109-L127
> Since this is region server specific code, not expecting this to happen when 
> one accesses hbase as a client.

This message was sent by Atlassian JIRA

Reply via email to