[
https://issues.apache.org/jira/browse/HADOOP-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795088#action_12795088
]
Chad Metcalf commented on HADOOP-6453:
--------------------------------------
Added:
{code}
JAVA_LIBRARY_PATH=`cygpath -p -w "$JAVA_LIBRARY_PATH"`
{code}
For trunk and 0.20 in the appropriate places. This now receives the same level
of protection that {{CLASSPATH}} does. As I acknowledged above there is indeed
a possibility that a user will have a broken {{JAVA_LIBRARY_PATH}} and this
will break for them. That possibility is slim. A quick google of
{{JAVA_LIBRARY_PATH}} brings this jira up as #5 which indicates its a
significantly less common env then {{CLASSPATH}}. Regardless the possibility
exists.
With the cygpath fix above this change makes every reasonable effort to protect
cygwin users. Which places them in the same boat as all the other bash users
(Linux, Mac, Solaris, etc). If you have a broken env there is nothing I can do.
It would the same if you had a broken {{CLASSPATH}}. As with all possibly
breaking changes there is a trade off between the users that need the
functionality and the users it will break.
Users that need to get native libraries in as it stands have to hack the
wrapper. This is tedious and error prone over setting a env. And its not
immediately obvious that its what you have to do. The wrapper script respects
{{CLASSPATH}} logically it should respect others. And its not documented that
if you want to do this, oh by the way you have to hack this.
I'm all for testing. But the risk here is broken user env's which is not
something in the scope of this jira to address. We can test the patch and add a
release note so that if it breaks someone they can read that this was changed.
If people are really that worried about it we can add:
{code}
echo "Existing JAVA_LIBRARY_PATH detected, if things are breaking please check
this first."
{code}
But most likely that will just send someone who breaks for a different reason
off on a 5 minute wild goose chase.
> Hadoop wrapper script shouldn't ignore an existing JAVA_LIBRARY_PATH
> --------------------------------------------------------------------
>
> Key: HADOOP-6453
> URL: https://issues.apache.org/jira/browse/HADOOP-6453
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.20.2, 0.21.0, 0.22.0
> Reporter: Chad Metcalf
> Assignee: Chad Metcalf
> Priority: Minor
> Fix For: 0.20.2, 0.21.0, 0.22.0
>
> Attachments: HADOOP-6453-0.20.patch, HADOOP-6453-0.20v2.patch,
> HADOOP-6453-trunkv2.patch, HADOOP-6453.trunk.patch
>
>
> Currently the hadoop wrapper script assumes its the only place that uses
> JAVA_LIBRARY_PATH and initializes it to a blank line.
> JAVA_LIBRARY_PATH=''
> This prevents anyone from setting this outside of the hadoop wrapper (say
> hadoop-config.sh) for their own native libraries.
> The fix is pretty simple. Don't initialize it to '' and append the native
> libs like normal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
