hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6834) HBaseClusterManager shell code breaks hadoop-2.0 build
Date Wed, 19 Sep 2012 03:01:07 GMT

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

stack commented on HBASE-6834:
------------------------------

+1 on the patch.  What you think Gregory (Given its a one liner maybe we put off pulling in
the Shell* classes?)
                
> HBaseClusterManager shell code breaks hadoop-2.0 build
> ------------------------------------------------------
>
>                 Key: HBASE-6834
>                 URL: https://issues.apache.org/jira/browse/HBASE-6834
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Gregory Chanan
>            Assignee: Enis Soztutar
>         Attachments: hbase-6834_v1.patch
>
>
> I get the following error:
> {noformat}
> HBaseClusterManager.java:[73,23] getExecString() in org.apache.hadoop.hbase.HBaseClusterManager.RemoteShell
cannot override getExecString() in org.apache.hadoop.util.Shell.ShellCommandExecutor; attempting
to assign weaker access privileges; was public
> {noformat}
> the issue is that getExecString() is declared public in hadoop-2.0, but protected in
hadoop-1.0.  In HBase, it is declared protected, and you can't downgrade from public to protected.
> We can just declare the function public and that seems to work, but given that in hadoop
the class is declared
> {code}
> @InterfaceAudience.LimitedPrivate({"HDFS", "MapReduce"})
> {code}
> perhaps we should just copy the class into hbase source.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message