[jira] [Commented] (IMPALA-7161) Bootstrap's handling of JAVA_HOME needs improvement
[
https://issues.apache.org/jira/browse/IMPALA-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773654#comment-16773654
]
ASF subversion and git services commented on IMPALA-7161:
-
Commit 6dabf9d9d3f6b4dc9ba287bbc8d712186589597f in impala's branch
refs/heads/2.x from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=6dabf9d ]
IMPALA-7161: Fix impala-config.sh's handling of JAVA_HOME
It is common for developers to specify JAVA_HOME in
bin/impala-config-local.sh, so wait until after it is
sourced to validate JAVA_HOME.
Also, try harder to auto-detect the system's JAVA_HOME
in case it has not been specified in the environment.
Here is a run through of different scenarios:
1. Not set in environment, not set in impala-config-local.sh:
Didn't work before, now tries to autodetect by looking
for javac on the PATH
2. Set in environment, not set in impala-config-local.sh:
No change
3. Not set in environment, set in impala-config-local.sh:
Didn't work before, now works
4. Set in environment and set in impala-config-local.sh:
This used to be potentially inconsistent (i.e. JAVA comes
from the environment's JAVA_HOME, but JAVA_HOME is
overwritten by impala-config-local.sh), now it always
uses the value from impala-config-local.sh.
Change-Id: Idf3521b4f44fdbdc841a90fd00c477c9423a75bb
Reviewed-on: http://gerrit.cloudera.org:8080/10702
Reviewed-by: Philip Zeyliger
Tested-by: Impala Public Jenkins
> Bootstrap's handling of JAVA_HOME needs improvement
> ---
>
> Key: IMPALA-7161
> URL: https://issues.apache.org/jira/browse/IMPALA-7161
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 2.13.0, Impala 3.1.0
>Reporter: Joe McDonnell
>Assignee: Joe McDonnell
>Priority: Major
> Fix For: Impala 3.1.0
>
>
> bin/bootstrap_system.sh installs the Java SDK and sets JAVA_HOME in the
> current shell. It also adds a command to the bin/impala-config-local.sh to
> export JAVA_HOME there. This doesn't do the job.
> bin/impala-config.sh tests for JAVA_HOME at the very start of the script,
> before it has sourced bin/impala-config-local.sh. So, the user doesn't have a
> way of developing over the long term without manually setting up JAVA_HOME.
> bin/impala-config.sh also doesn't detect the system JAVA_HOME. For Ubuntu
> 16.04, this is fairly simple and if a developer has their system JDK set up
> appropriately, it would make sense to use it. For example:
>
> {noformat}
> # If javac exists, then the system has a Java SDK (JRE does not have javac).
> # Follow the symbolic links and use this to determine the system's JAVA_HOME.
> if [ -L /usr/bin/javac ]; then
> SYSTEM_JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:bin/javac::")
> fi
> export JAVA_HOME="${JAVA_HOME:-${SYSTEM_JAVA_HOME}}"{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7161) Bootstrap's handling of JAVA_HOME needs improvement
[
https://issues.apache.org/jira/browse/IMPALA-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510039#comment-16510039
]
Philip Zeyliger commented on IMPALA-7161:
-
This all sounds good to me. I think if there's a working java on the path, we
should use it.
I found the following works for me:
{code}
export JAVA_HOME="$(jrunscript -e
'java.lang.System.out.println(java.lang.System.getProperty("java.home"));')"
{code}
I think the {{readlink}} approach is good too.
> Bootstrap's handling of JAVA_HOME needs improvement
> ---
>
> Key: IMPALA-7161
> URL: https://issues.apache.org/jira/browse/IMPALA-7161
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 2.13.0, Impala 3.1.0
>Reporter: Joe McDonnell
>Priority: Major
>
> bin/bootstrap_system.sh installs the Java SDK and sets JAVA_HOME in the
> current shell. It also adds a command to the bin/impala-config-local.sh to
> export JAVA_HOME there. This doesn't do the job.
> bin/impala-config.sh tests for JAVA_HOME at the very start of the script,
> before it has sourced bin/impala-config-local.sh. So, the user doesn't have a
> way of developing over the long term without manually setting up JAVA_HOME.
> bin/impala-config.sh also doesn't detect the system JAVA_HOME. For Ubuntu
> 16.04, this is fairly simple and if a developer has their system JDK set up
> appropriately, it would make sense to use it. For example:
>
> {noformat}
> # If javac exists, then the system has a Java SDK (JRE does not have javac).
> # Follow the symbolic links and use this to determine the system's JAVA_HOME.
> if [ -L /usr/bin/javac ]; then
> SYSTEM_JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:bin/javac::")
> fi
> export JAVA_HOME="${JAVA_HOME:-${SYSTEM_JAVA_HOME}}"{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7161) Bootstrap's handling of JAVA_HOME needs improvement
[
https://issues.apache.org/jira/browse/IMPALA-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509900#comment-16509900
]
Joe McDonnell commented on IMPALA-7161:
---
Additional issue:
Suppose a user sets JAVA_HOME in their environment like they are supposed to.
Suppose they also have JAVA_HOME in bin/impala-config-local.sh like
bin/bootstrap_system.sh writes. The two can get out of sync. The JAVA would be
from the environment JAVA_HOME, but after setting JAVA,
bin/impala-config-local.sh's value for JAVA_HOME would overwrite the
environment variable and JAVA_HOME would be that value. These could point to
two different places.
> Bootstrap's handling of JAVA_HOME needs improvement
> ---
>
> Key: IMPALA-7161
> URL: https://issues.apache.org/jira/browse/IMPALA-7161
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 2.13.0, Impala 3.1.0
>Reporter: Joe McDonnell
>Priority: Major
>
> bin/bootstrap_system.sh installs the Java SDK and sets JAVA_HOME in the
> current shell. It also adds a command to the bin/impala-config-local.sh to
> export JAVA_HOME there. This doesn't do the job.
> bin/impala-config.sh tests for JAVA_HOME at the very start of the script,
> before it has sourced bin/impala-config-local.sh. So, the user doesn't have a
> way of developing over the long term without manually setting up JAVA_HOME.
> bin/impala-config.sh also doesn't detect the system JAVA_HOME. For Ubuntu
> 16.04, this is fairly simple and if a developer has their system JDK set up
> appropriately, it would make sense to use it. For example:
>
> {noformat}
> # If javac exists, then the system has a Java SDK (JRE does not have javac).
> # Follow the symbolic links and use this to determine the system's JAVA_HOME.
> if [ -L /usr/bin/javac ]; then
> SYSTEM_JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:bin/javac::")
> fi
> export JAVA_HOME="${JAVA_HOME:-${SYSTEM_JAVA_HOME}}"{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
