[
https://issues.apache.org/jira/browse/MAPREDUCE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devaraj Das updated MAPREDUCE-1938:
-----------------------------------
Attachment: mr-1938-bp20.1.patch
Addressing Owen's comment on the shell script part of the patch.
Doug, this patch is a first step towards letting users use their own versions
of library provided implementation for things like CombineFileInputFormat. The
use case is to allow for specific implementations of library classes for
certain classes of jobs.
This doesn't aim to address the kernel/library separation in its entirety. So
yes, if the user puts a class on the classpath that doesn't work with the
kernel compatibly then tasks will fail, or produce obscure/inconsistent
results, but that will affect only that job, and the user would notice that
soon (hopefully). Did i understand your concern right?
> Ability for having user's classes take precedence over the system classes for
> tasks' classpath
> ----------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-1938
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1938
> Project: Hadoop Map/Reduce
> Issue Type: New Feature
> Components: job submission, task, tasktracker
> Reporter: Devaraj Das
> Fix For: 0.22.0
>
> Attachments: mr-1938-bp20.1.patch, mr-1938-bp20.patch
>
>
> It would be nice to have the ability in MapReduce to allow users to specify
> for their jobs alternate implementations of classes that are already defined
> in the MapReduce libraries. For example, an alternate implementation for
> CombineFileInputFormat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
