[
https://issues.apache.org/jira/browse/HADOOP-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla updated HADOOP-10043:
--------------------------------------
Attachment: potential-approach.patch
While the alternative approach that doesn't touch SecretManager is possible, it
does seem a lot more complicated than making SecretManager an AbstractService.
I am attaching a patch that details an approach that limits the changes to all
other SecretManagers. The behavior of these SecretManagers remains unchanged.
[~sureshms] - do you see any particular disadvantages to making SecretManager
an AbstractService?
> Convert org.apache.hadoop.security.token.SecretManager to be an
> AbstractService
> -------------------------------------------------------------------------------
>
> Key: HADOOP-10043
> URL: https://issues.apache.org/jira/browse/HADOOP-10043
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Tsuyoshi OZAWA
> Assignee: Tsuyoshi OZAWA
> Attachments: HADOOP-10043.1.patch, HADOOP-10043.2.patch,
> HADOOP-10043.3.patch, potential-approach.patch
>
>
> I'm dealing with YARN-1172, a subtask of YARN-1139(ResourceManager HA related
> task). The sentence as follows is a quoted from YARN-1172's my comment:
> {quote}
> I've found that it requires org.apache.hadoop.security.token.SecretManager to
> be an AbstractService,
> because both AbstractService and
> org.apache.hadoop.security.token.SecretManager are abstract class and we
> cannot extend both of them at the same time.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
