glassfish
  1. glassfish
  2. GLASSFISH-20008

asadmin produces bad error message when run with java earlier than Java SE 7

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b80_EE7MS6
    • Fix Version/s: 4.1
    • Component/s: command_line_interface
    • Labels:
      None
    • Environment:

      Windows 7 SP1
      Glassfish v4 b80 zipped version.

      Description

      Trying to run asadmin command from command line interface was failed and output the following error:

      E:\Utilities\Glassfish_v4\bin>asadmin
      Exception in thread "main" java.lang.UnsupportedClassVersionError: org/glassfish/admin/cli/AsadminMain : Unsupported major.minor version 51.0
              at java.lang.ClassLoader.defineClass1(Native Method)
              at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
              at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
              at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
              at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
              at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
              at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
              at java.security.AccessController.doPrivileged(Native Method)
              at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
              at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
      Could not find the main class: org.glassfish.admin.cli.AsadminMain. Program will exit.
      

      it is due to the default version in the system is JDK6, but the error is undescriptive and it should be somthing like "Unsupported JDK version, use JDK7 version.".

      when adding the following line to asenv.bat

      set AS_JAVA=C:\Program Files\Java\jdk1.7.0_17
      

      it works.

      Note: this was reported before and its status was fixed. (GLASSFISH-19486).

        Activity

        Hide
        Tom Mueller added a comment -

        The fix in GLASSFISH-19486 only applies to the server itself and the installer.
        If you use the zipped version (as indicated in the env. section here) and JDK 6 is on your PATH, then this error will result. We'll need to make the asadmin script deal with this. However, we don't want to do a version check everytime asadmin is run, because this will slow down the asadmin command. So asadmin must deal with the error somehow.

        Show
        Tom Mueller added a comment - The fix in GLASSFISH-19486 only applies to the server itself and the installer. If you use the zipped version (as indicated in the env. section here) and JDK 6 is on your PATH, then this error will result. We'll need to make the asadmin script deal with this. However, we don't want to do a version check everytime asadmin is run, because this will slow down the asadmin command. So asadmin must deal with the error somehow.
        Hide
        Tom Mueller added a comment -

        Ideally, the java CLI option -version:release could be used to insist on running with Java SE 7. However, this feature does not seem to be working. See JDK issue: https://jbs.oracle.com/bugs/browse/JDK-8011079

        Another option would be to have asadmin set the AS_JAVA variable in the asenv.conf/bat file if it is not already set. This would require write access to that file, which the user may not have. If the variable is not set, then the asadmin command execution will be slower because it has to check the java version. Once it is set, then execution speed would be the same as it is now. However, one potentially annoying problem with this solution is that if someone really wants the Java location to be taken from the PATH, this caching of the location would interfere with that.

        Show
        Tom Mueller added a comment - Ideally, the java CLI option -version:release could be used to insist on running with Java SE 7. However, this feature does not seem to be working. See JDK issue: https://jbs.oracle.com/bugs/browse/JDK-8011079 Another option would be to have asadmin set the AS_JAVA variable in the asenv.conf/bat file if it is not already set. This would require write access to that file, which the user may not have. If the variable is not set, then the asadmin command execution will be slower because it has to check the java version. Once it is set, then execution speed would be the same as it is now. However, one potentially annoying problem with this solution is that if someone really wants the Java location to be taken from the PATH, this caching of the location would interfere with that.
        Hide
        Tom Mueller added a comment -

        Here is a proposed fix for this bug:

        Use the AS_JAVA variable that can be defined in asenv.conf (or asenv.bat) to indicate whether the version has been checked. The asadmin command already reads this file and branches based on whether the value is there. The code could be modified in the case of it not being there to do a version check based on the java that is in the PATH, and if is a suitable version store AS_JAVA in the file for future use, if not print a good error message.

        This solution has the following drawbacks:

        1) The asenv.conf might not be writable. In that case, the code can just skip writing the file and asadmin will do the version check everytime, thereby making it slower. This case will probably happen rarely, so this drawback is probably acceptable.

        2) When the PATH is updated to point to a new java, asadmin will not pick it up. For example, on Windows each Java update is put into a new directory, such as C:\Program Files\Java\jdk1.7.0_11. When you install a new update, and delete the old version, your PATH now points to the new directory. However, the asenv.* file will still point to the old version. If the old version has been deleted, asadmin will fail. And the user has to now edit a config file that they may not even know is there. If the old version is still there, asadmin will not be using the version that the user intends (since they didn't set the AS_JAVA variable in the first place).

        So to fix (2), a solution may be to keep the AS_JAVA value and a "FROM_PATH" flag if it was set from the PATH. Then, if FROM_PATH is set, the script can compare the value of AS_JAVA and the current value of java from the PATH, and if they are different, the check would be redone and the new AS_JAVA would be stored. So this would handle the case if the PATH was changed.

        Show
        Tom Mueller added a comment - Here is a proposed fix for this bug: Use the AS_JAVA variable that can be defined in asenv.conf (or asenv.bat) to indicate whether the version has been checked. The asadmin command already reads this file and branches based on whether the value is there. The code could be modified in the case of it not being there to do a version check based on the java that is in the PATH, and if is a suitable version store AS_JAVA in the file for future use, if not print a good error message. This solution has the following drawbacks: 1) The asenv.conf might not be writable. In that case, the code can just skip writing the file and asadmin will do the version check everytime, thereby making it slower. This case will probably happen rarely, so this drawback is probably acceptable. 2) When the PATH is updated to point to a new java, asadmin will not pick it up. For example, on Windows each Java update is put into a new directory, such as C:\Program Files\Java\jdk1.7.0_11. When you install a new update, and delete the old version, your PATH now points to the new directory. However, the asenv.* file will still point to the old version. If the old version has been deleted, asadmin will fail. And the user has to now edit a config file that they may not even know is there. If the old version is still there, asadmin will not be using the version that the user intends (since they didn't set the AS_JAVA variable in the first place). So to fix (2), a solution may be to keep the AS_JAVA value and a "FROM_PATH" flag if it was set from the PATH. Then, if FROM_PATH is set, the script can compare the value of AS_JAVA and the current value of java from the PATH, and if they are different, the check would be redone and the new AS_JAVA would be stored. So this would handle the case if the PATH was changed.
        Hide
        Tom Mueller added a comment -
        • What is the impact on the customer of the bug? How likely is it that a customer will see the bug and how serious is the bug? Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? What CTS failures are caused by this bug?

        This bug would effect customers that do not have JDK 7 installed and on their PATH and which are using the ZIP distribution. All of the installer distributions check for the correct version and set the AS_JAVA variable appopriately. It is not a regression in that previous versions of GlassFish would fail in the same way if a version of Java was used that was too old. It does not cause CTS failures.

        • What is the cost/risk of fixing the bug? How risky is the fix? How much work is the fix? Is the
          fix complicated?

        The fix involved shell and BAT programming in the asadmin script. The work is probably 1-2 days and may involve complicated BAT scripting. The main risk is due to the various different Windows systems.

        • Is there an impact on documentation or message strings?

        No. However, the asadmin script would need to output an error message that is not translated since we can't translate a message from a BAT file.

        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

        Tests that exercise the asadmin command.

        • Which is the targeted build of 4.0 for this fix?

        b84

        • If this an integration of a new version of a component from another project,
          what are the changes that are being brought in? This might be list of
          Jira issues from that project or a list of revision messages.

        N/A

        Show
        Tom Mueller added a comment - What is the impact on the customer of the bug? How likely is it that a customer will see the bug and how serious is the bug? Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? What CTS failures are caused by this bug? This bug would effect customers that do not have JDK 7 installed and on their PATH and which are using the ZIP distribution. All of the installer distributions check for the correct version and set the AS_JAVA variable appopriately. It is not a regression in that previous versions of GlassFish would fail in the same way if a version of Java was used that was too old. It does not cause CTS failures. What is the cost/risk of fixing the bug? How risky is the fix? How much work is the fix? Is the fix complicated? The fix involved shell and BAT programming in the asadmin script. The work is probably 1-2 days and may involve complicated BAT scripting. The main risk is due to the various different Windows systems. Is there an impact on documentation or message strings? No. However, the asadmin script would need to output an error message that is not translated since we can't translate a message from a BAT file. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Tests that exercise the asadmin command. Which is the targeted build of 4.0 for this fix? b84 If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. N/A
        Hide
        Tom Mueller added a comment - - edited

        Here is a skeleton for a new asadmin script that could handle JDK version checking. This doesn't work completely yet.

        # Always use JDK 1.7 or higher
        AS_INSTALL=`dirname "$0"`/..
        case "`uname`" in
          CYGWIN*) AS_INSTALL=`cygpath --windows $AS_INSTALL`
        esac
        AS_INSTALL_LIB="$AS_INSTALL/lib"
        AS_CONF="$AS_INSTALL/config/asenv.conf"
        . "$AS_CONF"
        JAVA=java
        #Depends upon Java from $AS_CONF
        if [ ${AS_JAVA} ]; then
            JAVA=${AS_JAVA}/bin/java
            if [ ${AS_JAVA_FROM_PATH} ]; then
                # check to see if there is a new java in the PATH
                NEW_JAVA=`which java`
                if [ "${NEW_JAVA}" != "${JAVA}" ]; then
                    # check that this version will work
                    if $NEW_JAVA -version | grep -q 'java version "1.[78]'; then
                        # save this new version
                        mv $AS_CONF $AS_CONF.bak
                        grep -v AS_JAVA $AS_CONF.bak > $AS_CONF
                        echo AS_JAVA=$AS_JAVA >> $AS_CONF
                        echo AS_JAVA_FROM_PATH=true >> $AS_CONF
                        rm $AS_CONF.bak
                    else
                        echo "Invalid Java on PATH. Must be Java SE 7 or higher."
                    fi
                fi
            fi
        else 
            NEW_JAVA=`which java`
            if $NEW_JAVA -version | grep -q 'java version "1.[78]'; then
                # save this new version
                AS_JAVA=`java -XshowSettings 2>&1 | awk '/java.home/ {print $3}' | sed -e 's?/jre??' ` 
                echo AS_JAVA=$AS_JAVA >> $AS_CONF
                echo AS_JAVA_FROM_PATH=true >> $AS_CONF
            else
                echo "Invalid Java on PATH. Must be Java SE 7 or higher."
                exit 1
            fi
        fi
        exec "$JAVA" -jar "$AS_INSTALL_LIB/client/appserver-cli.jar" "$@"
        

        A .bat version of this hasn't been written yet.

        Show
        Tom Mueller added a comment - - edited Here is a skeleton for a new asadmin script that could handle JDK version checking. This doesn't work completely yet. # Always use JDK 1.7 or higher AS_INSTALL=`dirname "$0" `/.. case "`uname`" in CYGWIN*) AS_INSTALL=`cygpath --windows $AS_INSTALL` esac AS_INSTALL_LIB= "$AS_INSTALL/lib" AS_CONF= "$AS_INSTALL/config/asenv.conf" . "$AS_CONF" JAVA=java #Depends upon Java from $AS_CONF if [ ${AS_JAVA} ]; then JAVA=${AS_JAVA}/bin/java if [ ${AS_JAVA_FROM_PATH} ]; then # check to see if there is a new java in the PATH NEW_JAVA=`which java` if [ "${NEW_JAVA}" != "${JAVA}" ]; then # check that this version will work if $NEW_JAVA -version | grep -q 'java version "1.[78]'; then # save this new version mv $AS_CONF $AS_CONF.bak grep -v AS_JAVA $AS_CONF.bak > $AS_CONF echo AS_JAVA=$AS_JAVA >> $AS_CONF echo AS_JAVA_FROM_PATH= true >> $AS_CONF rm $AS_CONF.bak else echo "Invalid Java on PATH. Must be Java SE 7 or higher." fi fi fi else NEW_JAVA=`which java` if $NEW_JAVA -version | grep -q 'java version "1.[78]'; then # save this new version AS_JAVA=`java -XshowSettings 2>&1 | awk '/java.home/ {print $3}' | sed -e 's?/jre??' ` echo AS_JAVA=$AS_JAVA >> $AS_CONF echo AS_JAVA_FROM_PATH= true >> $AS_CONF else echo "Invalid Java on PATH. Must be Java SE 7 or higher." exit 1 fi fi exec "$JAVA" -jar "$AS_INSTALL_LIB/client/appserver-cli.jar" "$@" A .bat version of this hasn't been written yet.

          People

          • Assignee:
            Bhakti Mehta
            Reporter:
            Mohamed Taman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: