You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-issues@hadoop.apache.org by "Steve Loughran (JIRA)" <ji...@apache.org> on 2018/10/11 12:40:00 UTC

[jira] [Commented] (MAPREDUCE-243) Allow hadoop to run in an osgi container

    [ https://issues.apache.org/jira/browse/MAPREDUCE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646376#comment-16646376 ] 

Steve Loughran commented on MAPREDUCE-243:
------------------------------------------

revisiting this. I think it's time to close as a WONTFIX, as the trend towards isolation is generally some linux container. But we also need to embrace java 9+ module isolation to avoid transitive classpath hell. separate issue, covered elsewhere

> Allow hadoop to run in an osgi container
> ----------------------------------------
>
>                 Key: MAPREDUCE-243
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-243
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>            Reporter: David Savage
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>         Attachments: classpath.patch, tasklog.patch, taskrunner.patch, tasktracker.patch
>
>
> I have been running some tests getting hadoop to run within an osgi environment (specifically the Newton framework) and this has uncovered a number of minor bugs when mapred classes are instantiated from a different start point than their main methods.
> I have created a number of patches which I'll attach which solve these issues. It's possible these patches could be dealt with as separate issues but all are required to resolve the osgi issue. Happy to split up if easier to manage though.
> classpath.patch: this rearranges the classloader hierarchies for Task objects such that a Task is able to resolve api classes in the case where the api classes are no longer loaded from the system classloader.
> tasklog.patch: this ensures the log files are able to be resolved in the case where the child process is launched from a different directory to the parent process
> taskrunner.patch: this enables the TaskRunner to find a log dir in the case where the parent jvm is not launched by the hadoop scripts, also allows for a client to specify a substitute main class (which delegates to the TaskTracker$Child) in this case for purposes of resolving osgi classpaths but could be more general? Finally adds some extra logging in case where things go wrong.
> tasktracker.patch: allow parent to pass through configuration to child taskrunner (specifically in this case for purposes of passing classpath and laucher to taskrunner)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-help@hadoop.apache.org