[
https://issues.apache.org/jira/browse/MAPREDUCE-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753196#action_12753196
]
Chris K Wensel commented on MAPREDUCE-851:
------------------------------------------
Sorry, I haven't bothered with a patch for this as there hasn't been any public
comment.
In the meantime I've brute forced around this issue throughout my code. It
would be much cleaner if there weren't the random new Job() or new
TaskAttemptContext() strewn about.
One concern here is that a new Job() invokes a new Configuration() to wrap the
given Configuration default values.
In previous Hadoop releases, instantiating a JobConf in a task has been known
to freeze a child jvm during the xml parsing (no idea what caused this for
users).
There being a static block in Configuration for loading resources, I am unsure
how this will play out.
> Static job property accessors don't accept Configuration but various
> JobContext sub-classes
> -------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-851
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-851
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: client
> Affects Versions: 0.20.1
> Reporter: Chris K Wensel
>
> The current method of accepting only JobContext or one of its sub-classes
> adds much complexity to dynamic job configuration "builders" that manipulate
> the Configuration object in order to dynamically configure Hadoop jobs, and
> influence internal Hadoop sub-systems during runtime to provide higher level
> functions and features.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
