hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-16487) Remove Class.fromName("..PrefixTreeCodec") from TableMapReduceUtil addHBaseDependencyJars
Date Mon, 06 Nov 2017 06:22:00 GMT

     [ https://issues.apache.org/jira/browse/HBASE-16487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

stack resolved HBASE-16487.
    Resolution: Won't Fix

hbase-prefix-tree was removed in hbase2. Resolving as won't fix.

> Remove Class.fromName("..PrefixTreeCodec") from TableMapReduceUtil addHBaseDependencyJars
> -----------------------------------------------------------------------------------------
>                 Key: HBASE-16487
>                 URL: https://issues.apache.org/jira/browse/HBASE-16487
>             Project: HBase
>          Issue Type: Bug
>          Components: mapreduce
>    Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.2
>            Reporter: Matteo Bertozzi
> HBASE-15152 included the prefix tree module as dependency to TableMapReduceUtil. but
the hardcoded string of the class name was wrong. HBASE-16360 fixed the hardcoded string.

> but, I was looking at the comment above and I can't figure out where is the circular
> {code}
> // PrefixTreeCodec is part of the hbase-prefix-tree module. If not included in MR jobs
> // dependencies, MR jobs that write encoded hfiles will fail.
> // We used reflection here so to prevent a circular module dependency.
> // TODO - if we extract the MR into a module, make it depend on hbase-prefix-tree
> {code}
> from the pom.xml of the prefix-tree module I don't see hbase-server. but I can see prefix-tree
module in the hbase-server/pom.xml. the TableMapReduceUtil is in hbase-server.. so in theory
we don't have any circular dependency.
> we can just probably drop all that try/catch block with the Class.forName() and just
simply use org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeCodec as we do for the others.

> (or at least we should end up with a test to cover the that Class.fromName() in case
we rename the PrefixTreeCodec or the namespace in the future and forget to update this reference)

This message was sent by Atlassian JIRA

View raw message