[
https://issues.apache.org/jira/browse/HADOOP-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806180#action_12806180
]
Chris Douglas commented on HADOOP-6299:
---------------------------------------
bq. I'd be much more comfortable with that policy if a patch had been approved
by consensus that actually added the annotations to all unstable public
classes. Without that, our users have no ability to see what's stable and
what's not. This policy been subject to any vote, only the code that permits us
to declare scopes has.
HADOOP-5073 had nearly a year of discussion before it was committed; that
clause was in the first draft. Still, if you feel strongly about it, start a
discussion and call a vote. In Hadoop, a whitelist of "this is public" makes a
lot more sense to me than a blacklist of "this is private," but I can see why
some users would disagree.
bq. UnixUserGroupInformation.java was added as a public class in December of
2007, in HADOOP-2299. At that point in time Java visibility was used to define
back-compatibility constraints.
Really? The scope of our back-compatibility constraints was not defined, which
I thought was the motivation of HADOOP-5073. Asserting that this undocumented
policy should apply to this issue until HADOOP-5073 gets even more discussion
isn't a gap easily bridged for me. Is functionality lost when
UnixUserGroupInformation is removed or is it redundant in the new code? Is the
issue only that a public class was removed without first deprecating it?
> Use JAAS LoginContext for our login
> -----------------------------------
>
> Key: HADOOP-6299
> URL: https://issues.apache.org/jira/browse/HADOOP-6299
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Arun C Murthy
> Assignee: Owen O'Malley
> Fix For: 0.22.0
>
> Attachments: 6299-MR-early.patch, h-6299.patch, h-6299.patch,
> h-6299.patch, h-6299.patch, h-6299.patch, HADOOP-6299-2.patch,
> UserGroupInformation.java, UserGroupInformation.java
>
>
> Currently we use a custom login module in UnixUserGroupInformation for
> acquiring user-credentials (via config or exec'ing 'whoami'). We should
> switch to using standard JAAS components such as LoginContext and possibly
> implement a custom UnixLoginContext for our current requirements. In future
> we can use this for Kerberos etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
