Karaf
  1. Karaf
  2. KARAF-2270

Service wrapper assumes java is on system path

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.1
    • Fix Version/s: 2.3.3, 2.4.0, 3.0.0
    • Component/s: karaf-os-integration
    • Labels:
      None
    • Environment:

      windows, linux

      Description

      In the service wrapper conf file, the wrapper.java.command property points directly to java, and not to a fully qualified path to java. This assumes that java is on the system path, which it may not. The value should be:

      wrapper.java.command=%JAVA_HOME%/bin/java

      This ensures the wrapper is using the java executable established from setting the JAVA_HOME variable under the Wrapper Properties a few lines up in the conf file.

        Activity

        Hide
        Jean-Baptiste Onofré added a comment -

        Finally, remove the JAVA_HOME settings in karaf-service script (to avoid to override the JAVA_HOME defined in karaf-wrapper.conf) and documentation updated on karaf-2.3.x: http://svn.apache.org/viewvc?view=revision&revision=1518491

        Show
        Jean-Baptiste Onofré added a comment - Finally, remove the JAVA_HOME settings in karaf-service script (to avoid to override the JAVA_HOME defined in karaf-wrapper.conf) and documentation updated on karaf-2.3.x: http://svn.apache.org/viewvc?view=revision&revision=1518491
        Hide
        Jean-Baptiste Onofré added a comment -

        Update karaf-service script on karaf-2.x: http://svn.apache.org/viewvc?view=revision&revision=1518481

        Show
        Jean-Baptiste Onofré added a comment - Update karaf-service script on karaf-2.x: http://svn.apache.org/viewvc?view=revision&revision=1518481
        Hide
        Jean-Baptiste Onofré added a comment -
        Show
        Jean-Baptiste Onofré added a comment - Update karaf-service script on trunk: http://svn.apache.org/viewvc?view=revision&revision=1518477
        Hide
        Jean-Baptiste Onofré added a comment -

        On the other hand, I'm documenting the JAVA_HOME settings in the wrapper.

        Show
        Jean-Baptiste Onofré added a comment - On the other hand, I'm documenting the JAVA_HOME settings in the wrapper.
        Hide
        Jean-Baptiste Onofré added a comment -

        You are right (I missed the -z test).

        IMHO, I would prefer to set the karaf-wrapper.conf as it is, and don't set the JAVA_HOME at all in the karaf-service script (in order to use the one provided in the karaf-wrapper.conf).

        Show
        Jean-Baptiste Onofré added a comment - You are right (I missed the -z test). IMHO, I would prefer to set the karaf-wrapper.conf as it is, and don't set the JAVA_HOME at all in the karaf-service script (in order to use the one provided in the karaf-wrapper.conf).
        Hide
        Opher Shachar added a comment -

        Hello Jean,
        It seems to me that the change to karaf-service is functionally equivalent to the previous version:

        • If JAVA_HOME environment variable is set (eg. to the system default JDK since the script is invoked by init) then the check [ -z $JAVA_HOME ] fails and the script wont change JAVA_HOME environment variable.
        • If JAVA_HOME environment variable is unset the script will set it to the system default JDK (or JRE).
        • If no system default java is installed the script leaves JAVA_HOME environment variable unset, causing only in this scenario wrapper.conf's default JAVA_HOME to kick in.

        ...and so it doesn't fix the issue in your comment:

        I reopen this issue because the karaf-service script ignores the JAVA_HOME define in the wrapper.conf file and always override it using readlink.

        Consider the case where there is a system default JDK installed that is not compatible with Karaf (eg. JDK 1.5 installed as a system default).
        Since the script is invoked by init there is no outside way to set JAVA_HOME to a compatible JDK 1.6 installed somewhere in the system (that was set in wrapper.conf by the install process). The result will always be that the wrapper tries to invoke Karaf with a JDK 1.5 and fails.
        Perhaps you could consider changing wrapper.conf's behavior to set the JDK home ignoring JAVA_HOME environment variable — by changing:

        set.default.JAVA_HOME=${java.home}

        to

        set.JAVA_HOME=${java.home}

        or loosing the code in the service-script that mangles JAVA_HOME,
        or documenting that hand editing the service-script is necessary in such a scenario.

        Show
        Opher Shachar added a comment - Hello Jean, It seems to me that the change to karaf-service is functionally equivalent to the previous version: If JAVA_HOME environment variable is set (eg. to the system default JDK since the script is invoked by init ) then the check [ -z $JAVA_HOME ] fails and the script wont change JAVA_HOME environment variable. If JAVA_HOME environment variable is unset the script will set it to the system default JDK (or JRE). If no system default java is installed the script leaves JAVA_HOME environment variable unset, causing only in this scenario wrapper.conf 's default JAVA_HOME to kick in. ...and so it doesn't fix the issue in your comment: I reopen this issue because the karaf-service script ignores the JAVA_HOME define in the wrapper.conf file and always override it using readlink. Consider the case where there is a system default JDK installed that is not compatible with Karaf (eg. JDK 1.5 installed as a system default). Since the script is invoked by init there is no outside way to set JAVA_HOME to a compatible JDK 1.6 installed somewhere in the system (that was set in wrapper.conf by the install process). The result will always be that the wrapper tries to invoke Karaf with a JDK 1.5 and fails. Perhaps you could consider changing wrapper.conf 's behavior to set the JDK home ignoring JAVA_HOME environment variable — by changing: set. default .JAVA_HOME=${java.home} to set.JAVA_HOME=${java.home} or loosing the code in the service-script that mangles JAVA_HOME, or documenting that hand editing the service-script is necessary in such a scenario.
        Hide
        Jean-Baptiste Onofré added a comment -

        Fixed JAVA_HOME retrieval and service script on karaf-2.3.x branch: http://svn.apache.org/viewvc?view=revision&revision=1517771

        Show
        Jean-Baptiste Onofré added a comment - Fixed JAVA_HOME retrieval and service script on karaf-2.3.x branch: http://svn.apache.org/viewvc?view=revision&revision=1517771
        Hide
        Jean-Baptiste Onofré added a comment -

        Fixed JAVA_HOME retrieval and service script on karaf-2.x branch: http://svn.apache.org/viewvc?view=revision&revision=1517767

        Show
        Jean-Baptiste Onofré added a comment - Fixed JAVA_HOME retrieval and service script on karaf-2.x branch: http://svn.apache.org/viewvc?view=revision&revision=1517767
        Hide
        Jean-Baptiste Onofré added a comment -

        Fixed JAVA_HOME retrieval and service script on trunk: http://svn.apache.org/viewvc?view=revision&revision=1517766

        Show
        Jean-Baptiste Onofré added a comment - Fixed JAVA_HOME retrieval and service script on trunk: http://svn.apache.org/viewvc?view=revision&revision=1517766
        Hide
        Jean-Baptiste Onofré added a comment -

        More over, wrapper:install use System.getProperty("java.home") to get the JAVA_HOME, but it gets the JRE home (as expected). So, the wrapper:install should use System.getenv("JAVA_HOME") to get the actual JAVA_HOME.

        Show
        Jean-Baptiste Onofré added a comment - More over, wrapper:install use System.getProperty("java.home") to get the JAVA_HOME, but it gets the JRE home (as expected). So, the wrapper:install should use System.getenv("JAVA_HOME") to get the actual JAVA_HOME.
        Hide
        Jean-Baptiste Onofré added a comment -

        I reopen this issue because the karaf-service script ignores the JAVA_HOME define in the wrapper.conf file and always override it using readlink.

        Show
        Jean-Baptiste Onofré added a comment - I reopen this issue because the karaf-service script ignores the JAVA_HOME define in the wrapper.conf file and always override it using readlink.
        Hide
        Jean-Baptiste Onofré added a comment -

        As reminder, we still use JSW 3.2.3 (latest version compliant with the Apache license).

        Show
        Jean-Baptiste Onofré added a comment - As reminder, we still use JSW 3.2.3 (latest version compliant with the Apache license).
        Hide
        Jean-Baptiste Onofré added a comment -

        Use JAVA_HOME in the wrapper.java.command property on trunk: http://svn.apache.org/viewvc?view=revision&revision=1499091

        Show
        Jean-Baptiste Onofré added a comment - Use JAVA_HOME in the wrapper.java.command property on trunk: http://svn.apache.org/viewvc?view=revision&revision=1499091
        Hide
        Jean-Baptiste Onofré added a comment -

        Use JAVA_HOME in the wrapper.java.command property on karaf-2.x: http://svn.apache.org/viewvc?view=revision&revision=1499086

        Show
        Jean-Baptiste Onofré added a comment - Use JAVA_HOME in the wrapper.java.command property on karaf-2.x: http://svn.apache.org/viewvc?view=revision&revision=1499086
        Hide
        Jean-Baptiste Onofré added a comment -

        Use JAVA_HOME in the wrapper.java.command property on karaf-2.3.x: http://svn.apache.org/viewvc?view=revision&revision=1499080

        Show
        Jean-Baptiste Onofré added a comment - Use JAVA_HOME in the wrapper.java.command property on karaf-2.3.x: http://svn.apache.org/viewvc?view=revision&revision=1499080
        Hide
        Jean-Baptiste Onofré added a comment -

        Fair enough Brian. I'm gonna take a look on that.

        Show
        Jean-Baptiste Onofré added a comment - Fair enough Brian. I'm gonna take a look on that.
        Hide
        Brian Emond added a comment -

        Please see my latest comment, I think this needs additional review.

        Show
        Brian Emond added a comment - Please see my latest comment, I think this needs additional review.
        Hide
        Brian Emond added a comment -

        Guys, I understand what you're saying about the user setting up java before running karaf, but that doesn't mean requiring java to be on the SYSTEM path before execution. For the service wrapper, that is exactly why you set the JAVA_HOME variable at the top of your wrapper.conf. And in fact, the karaf-service linux script makes sure JAVA_HOME is set as the first thing they do! You even corrected this as part of karaf issue KARAF-2017, but then you're not using it to invoke java itself.

        If you look at this <a href=http://wrapper.tanukisoftware.com/doc/english/props-envvars.html>Java Service Wrapper documentation page</a>, even they demonstrate that you should be invoking java on the wrapper.java.command property using the JAVA_HOME variable. What sense does it make to set JAVA_HOME in your conf file, reference it for additional java parameters, but yet not use it to invoke java itself and instead require java to be configured on the system path?

        I apologize if I'm fundamentally missing something here, but this seems to be a big mistake to me. I'll reopen for additional discussion.

        Show
        Brian Emond added a comment - Guys, I understand what you're saying about the user setting up java before running karaf, but that doesn't mean requiring java to be on the SYSTEM path before execution. For the service wrapper, that is exactly why you set the JAVA_HOME variable at the top of your wrapper.conf. And in fact, the karaf-service linux script makes sure JAVA_HOME is set as the first thing they do! You even corrected this as part of karaf issue KARAF-2017 , but then you're not using it to invoke java itself. If you look at this <a href= http://wrapper.tanukisoftware.com/doc/english/props-envvars.html >Java Service Wrapper documentation page</a>, even they demonstrate that you should be invoking java on the wrapper.java.command property using the JAVA_HOME variable. What sense does it make to set JAVA_HOME in your conf file, reference it for additional java parameters, but yet not use it to invoke java itself and instead require java to be configured on the system path? I apologize if I'm fundamentally missing something here, but this seems to be a big mistake to me. I'll reopen for additional discussion.
        Hide
        Jean-Baptiste Onofré added a comment -

        Agree with Dan, it's up to the user to adapt karaf-wrapper.conf to the environment.

        Show
        Jean-Baptiste Onofré added a comment - Agree with Dan, it's up to the user to adapt karaf-wrapper.conf to the environment.
        Hide
        Dan Tran added a comment -

        I disagree with this solution, JAVA_HOME is not available for system like redhat linux. On windows It is always under system path

        User is responsible to prep up java path before starting karaf

        Show
        Dan Tran added a comment - I disagree with this solution, JAVA_HOME is not available for system like redhat linux. On windows It is always under system path User is responsible to prep up java path before starting karaf

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Brian Emond
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development