> On June 15, 2014, 2:03 a.m., Rohini Palaniswamy wrote:
> > core/src/main/java/org/apache/oozie/service/ShareLibService.java, line 96
> > <https://reviews.apache.org/r/19929/diff/6-7/?file=599794#file599794line96>
> >
> >     You can just return this fs object
> 
> Benjamin Zhitomirsky wrote:
>     This won't be right, because if sysLibPath is a full qualified path than 
> fs would not be the right filesystem.
>     Of cause I may check for authority in sysLibPath and if not present then 
> return fs, otherwise call getFileSystem().

This fs is constructed by doing fs = 
FileSystem.get(has.createJobConf(uri.getAuthority())); and should take care of 
the case where uri authority is null or if it is fully qualified for system lib 
path. Why do you want to construct fs by always passing null for authority?


- Rohini


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19929/#review45702
-----------------------------------------------------------


On June 14, 2014, 7:27 p.m., Benjamin Zhitomirsky wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19929/
> -----------------------------------------------------------
> 
> (Updated June 14, 2014, 7:27 p.m.)
> 
> 
> Review request for oozie.
> 
> 
> Repository: oozie-git
> 
> 
> Description
> -------
> 
> When <name-node> element in Oozie workflow specifies a name node different 
> from the default one (specified in core-site.xml), the following 
> functionality doesn’t work properly:
> ?Location of libraries specified via 
> oozie.service.WorkflowAppService.system.libpath. Oozie first (during launcher 
> configuration) tries to locate them using name node specified by the 
> <name-node> element, but later during job submission it expects this path to 
> be under the default Oozie name node
> ?Processing of the job-xml element if job xml is specified via absolute path. 
> Oozie tries locate it under the default Oozie name node instead of the 
> name-node specified in action.
> 
> Specifying non-default name node makes a lot of sense in Azure environment, 
> because it allows to submit the same job to different Hadoop clusters.
> 
> 
> Diffs
> -----
> 
>   core/src/main/java/org/apache/oozie/action/hadoop/JavaActionExecutor.java 
> 40add2c 
>   core/src/main/java/org/apache/oozie/service/HadoopAccessorService.java 
> bb68b0e 
>   core/src/main/java/org/apache/oozie/service/ShareLibService.java 320af8b 
>   core/src/main/java/org/apache/oozie/util/JobUtils.java 135b096 
>   
> core/src/test/java/org/apache/oozie/action/hadoop/ActionExecutorTestCase.java 
> bc2c1b6 
>   
> core/src/test/java/org/apache/oozie/action/hadoop/TestJavaActionExecutor.java 
> 390ad3f 
>   core/src/test/java/org/apache/oozie/test/XFsTestCase.java 18cb742 
>   core/src/test/java/org/apache/oozie/test/XTestCase.java 1536927 
>   docs/src/site/twiki/WorkflowFunctionalSpec.twiki f7590d0 
> 
> Diff: https://reviews.apache.org/r/19929/diff/
> 
> 
> Testing
> -------
> 
> On deployed Hadoop cluster. Two tests were added.
> 
> 
> Thanks,
> 
> Benjamin Zhitomirsky
> 
>

Reply via email to