[
https://issues.apache.org/jira/browse/ACCUMULO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556550#comment-13556550
]
Billie Rinaldi commented on ACCUMULO-769:
-----------------------------------------
The trunk changes broke the hadoop 2.0 build due to the use of the
TaskAttemptContext constructor. However, the two methods marked as deprecated
that instantiate TaskAttemptContext, initialize(InputSplit inSplit,
Configuration conf) and getSplits(Configuration conf), are actually new in
trunk and can be removed instead of deprecated. We should check over 1.5.0
before release and make sure nothing else is both new and deprecated.
> MapReduce API should not use Configuration to set Job state at submission
> time (ambiguous semantics)
> ----------------------------------------------------------------------------------------------------
>
> Key: ACCUMULO-769
> URL: https://issues.apache.org/jira/browse/ACCUMULO-769
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Affects Versions: 1.4.1, 1.4.0
> Reporter: Christopher Tubbs
> Assignee: Christopher Tubbs
> Priority: Minor
> Fix For: 1.5.0
>
>
> ACCUMULO-267 made this change, but I think it was the wrong way to go about
> it.
> From the comments on ACCUMULO-267:
> This is the wrong way to go about doing this fix. The reason why it took a
> JobContext is so that it could accept a "Job" object. This was modeled after
> the pattern Hadoop was using for FileOutputFormat, which is somewhat the
> standard for conventions in configuring MR jobs.
> While JobContext does specifically state that's what it's purpose is, it is a
> base class, and Job extends JobContext, and includes a comment that describes
> it as holding the state of the job at submission time. This API should really
> be taking a "Job" object, rather than a "JobContext" object. Further, because
> Job is the only JobContext that actually works as intended here, the change
> from JobContext to Job does not require any deprecation, because Job will
> still work, and any other JobContext that isn't a Job will still fail. (We
> would have to deprecate the ones that were added in 1.4 that took a
> Configuration object, though... because those were never "correct", if we are
> going off of the conventions set by Hadoop's provided OutputFormats).
> It is somewhat annoying to deprecate something in 1.5 that was added in
> 1.4... especially since it allows people to go back to what they were doing
> before. But, I think it might be worth it to be consistent with the
> established conventions, and to clarify the semantics of the methods (we are,
> after all, modifying the state of a job we are about to submit, and not just
> an arbitrary configuration, which is used for all sorts of things).
--
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
