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

Alex Holmes commented on HADOOP-10820:
--------------------------------------

Since the string-based constructor checks for an empty string, for consistency 
it would make sense that the URI-based constructor do the same thing.

What would be the desired user experience in the case of an empty token entry 
in libjars - throwing an exception from the Path constructor, or handling it as 
per this patch and allowing the command to continue? If it's the later then it 
would make sense to commit this patch.

In both cases it seems like a new ticket needs to be opened to check for an 
empty URI in the constructor - please let me know if you'd like me to do that.

> Empty entry in libjars results in working directory being recursively 
> localized
> -------------------------------------------------------------------------------
>
>                 Key: HADOOP-10820
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10820
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Alex Holmes
>            Priority: Minor
>         Attachments: HADOOP-10820-1.patch, HADOOP-10820.patch
>
>
> An empty token (e.g. "a.jar,,b.jar") in the -libjars option causes the 
> current working directory to be recursively localized.
> Here's an example of this in action (using Hadoop 2.2.0):
> {code}
> # create a temp directory and touch three JAR files
> mkdir -p tmp/path && cd tmp && touch a.jar b.jar c.jar path/d.jar
> # Run an example job only specifying two of the JARs.
> # Include an empty entry in libjars.
> hadoop jar 
> /usr/local/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.2.0.jar 
> pi -libjars a.jar,,c.jar 2 1000000000
> # As the job is running examine the localized directory in HDFS.
> # Notice that not only are the two JAR's specified in libjars copied,
> # but in addition the contents of the working directory are also recursively 
> copied.
> $ hadoop fs -lsr 
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/a.jar
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/c.jar
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp/a.jar
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp/b.jar
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp/c.jar
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp/path
> /tmp/hadoop-yarn/staging/aholmes/.staging/job_1404752711144_0018/libjars/tmp/path/d.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to