Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8155076

Webstart loads JARs from MANIFEST.MF after loading the jars from resources-tag

    Details

    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:
      b124
    • CPU:
      x86_64
    • OS:
      windows_7
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.8.0_92"
        Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
        Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

        ADDITIONAL OS VERSION INFORMATION :
        Microsoft Windows [Version 6.1.7601]
        MacOS X 10.11.4 (15E65)
        Linux r2d2 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        Layout on the Server

        Dachsweb.jar
        lib.signed <- signed libs in her
        lib <- there were the unsigned libs, wich shouldn't be used

        see workaround

        A DESCRIPTION OF THE PROBLEM :
        The apache-webserver access.log indicates, that the Webstart-classloader tries to load the classes from the Manifest.MF inside the main-jar after it loaded the jars from the
        resources-Tag

        <resources>
                <jar href="Dachsweb.jar" main="true"/>
                <jar href="lib.signed/Dachsweb-common.jar"/>
        ...
        </resources>

        Manifest.mf from Dachsweb.jar
        Class-Path: lib/Dachsweb-common.jar ....

        This should not be the case




        REGRESSION. Last worked in version 8u77

        ADDITIONAL REGRESSION INFORMATION:
        java version "1.8.0_77"
        Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
        Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Start
        http://commserver.senertec.com/dachsweb/Dachsweb.jnlp

        with 1.8.0_92 or 1.8.0_91
        -> Console shows, that it tries to load lib.signed/lib/Dachsweb-common.jar which doesn't exist
        Note! ..this would be a failure, if we wouldn't have installed a workaround

        with 1.8.0_77
        it just loads the jars specified by the webstart-file

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        Apache Access-Log like in 1.8.0_77

        x.x.x.x - - [17/Apr/2016:08:19:35 +0200] "GET /dachsweb/Dachsweb.jar HTTP/1.1" 304 191 "-" "JNLP/1.7.0 javaws/11.77.2.03 (<internal>) Java/1.8.0_77"
        ..
        x.x.x.x - - [17/Apr/2016:08:19:35 +0200] "GET /dachsweb/lib.signed/Dachsweb-common.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.77.2.03 (<internal>) Java/1.8.0_77"
        ..
        <no wrong entries>

        ACTUAL -
        Apache Access-Log 1.8.0_91 (it doesn't matter if 91 or 92)

        x.x.x.x - - [20/Apr/2016:09:16:18 +0200] "GET /dachsweb/Dachsweb.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.91.2.14 (<internal>) Java/1.8.0_91"
        ..
        x.x.x.x - - [20/Apr/2016:09:16:18 +0200] "GET /dachsweb/lib.signed/Dachsweb-common.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.91.2.14 (<internal>) Java/1.8.0_91"
        ... no the wrong entries (not lib/lib is not in the MANIFEST.MF)
        x.x.x.x - - [20/Apr/2016:09:16:34 +0200] "GET /dachsweb/lib/Dachsweb-common.jar HTTP/1.1" 200 1494120 "-" "Java/1.8.0_91"
        x.x.x.x - - [20/Apr/2016:09:16:39 +0200] "GET /dachsweb/lib/lib/Dachsweb-common.jar HTTP/1.1" 404 563 "-" "Java/1.8.0_91"

        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        Without workaround you get Cert-errors and java.lang.NoClassDefFoundError

        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        We had to change the dir-layout on the server
        $ mv lib lib.unsigned
        $ ln -s lib.signed lib

        so that it works again

        It gets loaded twice nonetheless .

          Issue Links

            Activity

            Hide
            pardesha Pardeep Sharma added a comment - - edited
            Additional information from the submitter:
            =====================================================================
            The Webstart-Application is under
            http://commserver.senertec.com/dachsweb/Dachsweb-test.jnlp

            This works with java8u77 - not with java8u91
            - java8u77 loads just the jars from the JNLP-File
            - java8u91 tries to load jars from the Class-path in the Manifest.MF of some jars

            This leads to a another problem (signer IS NULL)

            see
            8u91 JNLPClassLoader is broken
            https://community.oracle.com/thread/3921768
            =================================================================
            Show
            pardesha Pardeep Sharma added a comment - - edited Additional information from the submitter: ===================================================================== The Webstart-Application is under http://commserver.senertec.com/dachsweb/Dachsweb-test.jnlp This works with java8u77 - not with java8u91 - java8u77 loads just the jars from the JNLP-File - java8u91 tries to load jars from the Class-path in the Manifest.MF of some jars This leads to a another problem (signer IS NULL) see 8u91 JNLPClassLoader is broken https://community.oracle.com/thread/3921768 =================================================================
            Hide
            pardesha Pardeep Sharma added a comment - - edited
            Checked this for 8u77, 8u91/92 and 8u102 ea b04.
            Result:
            ===========================
            8u77 b03: OK (Works)
            8u91 b14: FAIL
            8u92 b14: FAIL
            8u102 ea b04: FAIL
            ========================================================
            To reproduce, run the following test jnlp with respective version:
            http://commserver.senertec.com/dachsweb/Dachsweb-test.jnlp

            See link to screenshots for reference. The issue is reproducible with 8u91, 8u92 and 8u102 b04 - The loading takes a long tine and shows "Before Class.forName" Message and exits after click (no log and no Message-Dialog, no thread.sleep)
            Show
            pardesha Pardeep Sharma added a comment - - edited Checked this for 8u77, 8u91/92 and 8u102 ea b04. Result: =========================== 8u77 b03: OK (Works) 8u91 b14: FAIL 8u92 b14: FAIL 8u102 ea b04: FAIL ======================================================== To reproduce, run the following test jnlp with respective version: http://commserver.senertec.com/dachsweb/Dachsweb-test.jnlp See link to screenshots for reference. The issue is reproducible with 8u91, 8u92 and 8u102 b04 - The loading takes a long tine and shows "Before Class.forName" Message and exits after click (no log and no Message-Dialog, no thread.sleep)
            Hide
            alitvinov Anton Litvinov added a comment -
            Was able to observe that:
            1. The user's application was being loaded for more than 5 minutes with JRE 8u77 b03 and after that the application ran and exited itself. No exceptions were found in Java Web Start trace files.
            2. The user's application was being loaded also for more than 5 minutes with JRE 8u92 b14, but after that the application ran and it took the application about 4 minutes to run and exit. Numerous exceptions like

            "java.io.IOException: Server returned HTTP response code: 403 for URL: http://commserver.senertec.com/dachsweb/lib.signed/lib/Dachsweb-common.jar"

            were found in Java Web Start trace files, HOWEVER the specified in the comment () exception "java.lang.SecurityException: class "org.jboss.logging.LoggerProviders"'s signer information does not match signer information of other classes in the same package" could not be reproduced.

            Trying to identify the reason of why in JRE 8u92 b14 JAR file with relative path like "lib.signed/Dachsweb-common.jar" is being downloaded by the incorrect relative path "lib.signed/lib/Dachsweb-common.jar" which contains extra "lib" directory. In order to do this it is necessary to create the minimal test case. Starting work on creation of the minimal test case.
            Show
            alitvinov Anton Litvinov added a comment - Was able to observe that: 1. The user's application was being loaded for more than 5 minutes with JRE 8u77 b03 and after that the application ran and exited itself. No exceptions were found in Java Web Start trace files. 2. The user's application was being loaded also for more than 5 minutes with JRE 8u92 b14, but after that the application ran and it took the application about 4 minutes to run and exit. Numerous exceptions like "java.io.IOException: Server returned HTTP response code: 403 for URL: http://commserver.senertec.com/dachsweb/lib.signed/lib/Dachsweb-common.jar " were found in Java Web Start trace files, HOWEVER the specified in the comment () exception "java.lang.SecurityException: class "org.jboss.logging.LoggerProviders"'s signer information does not match signer information of other classes in the same package" could not be reproduced. Trying to identify the reason of why in JRE 8u92 b14 JAR file with relative path like "lib.signed/Dachsweb-common.jar" is being downloaded by the incorrect relative path "lib.signed/lib/Dachsweb-common.jar" which contains extra "lib" directory. In order to do this it is necessary to create the minimal test case. Starting work on creation of the minimal test case.
            Hide
            herrick Andy Herrick added a comment -
            This is a regression, it also occurs in JDK9 .
            The Main-Class manifest attribute is supposed to be usable in Java Plugin, but ignored by Java Web Start (as per jnlp specification section 4.3.1)
            A simple test has been posted at: http://oklahoma.us.oracle.com/www/tests/manifest/test.jnlp
            The jnlp file contains only one jar file, hello.jar. When you click on the "show dialogs" it tries to load code from TestDeploy.jar.
            TestDeploy.jar is listed in the Class-Path manifest attribute, so it should not be loaded. You can see in JDK9, this will throw an AccessViloation (showing that it was called) or in 8u it will start showing dialogs (also showing that it was loaded)

            The code in CachedJarFile.getManifest is supposed to prevent this.
            Show
            herrick Andy Herrick added a comment - This is a regression, it also occurs in JDK9 . The Main-Class manifest attribute is supposed to be usable in Java Plugin, but ignored by Java Web Start (as per jnlp specification section 4.3.1) A simple test has been posted at: http://oklahoma.us.oracle.com/www/tests/manifest/test.jnlp The jnlp file contains only one jar file, hello.jar. When you click on the "show dialogs" it tries to load code from TestDeploy.jar. TestDeploy.jar is listed in the Class-Path manifest attribute, so it should not be loaded. You can see in JDK9, this will throw an AccessViloation (showing that it was called) or in 8u it will start showing dialogs (also showing that it was loaded) The code in CachedJarFile.getManifest is supposed to prevent this.
            Hide
            mcherkas Mikhail Cherkasov (Inactive) added a comment -
            [~herrick] CachedJarFile.getManifest was removed by https://bugs.openjdk.java.net/browse/JDK-8140400 . I moved getManifest method back from CaceEntry to CachedJarFile, it works fine for jdk8, but I'm still waiting for customer's feedback. however the fix doesn't work for jdk9, now I'm debugging it, looks like I made a mistake during forwardporting.
            Show
            mcherkas Mikhail Cherkasov (Inactive) added a comment - [~herrick] CachedJarFile.getManifest was removed by https://bugs.openjdk.java.net/browse/JDK-8140400 . I moved getManifest method back from CaceEntry to CachedJarFile, it works fine for jdk8, but I'm still waiting for customer's feedback. however the fix doesn't work for jdk9, now I'm debugging it, looks like I made a mistake during forwardporting.
            Show
            mcherkas Mikhail Cherkasov (Inactive) added a comment - review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1998
            Hide
            afomin Alexander Fomin (Inactive) added a comment -
            No nightly issues related to the fix in the Deployment nightly. UR SQE OK to take it in CPU16_03
            Show
            afomin Alexander Fomin (Inactive) added a comment - No nightly issues related to the fix in the Deployment nightly. UR SQE OK to take it in CPU16_03
            Hide
            mcherkas Mikhail Cherkasov (Inactive) added a comment -
            Show
            mcherkas Mikhail Cherkasov (Inactive) added a comment - Regression was caused by https://bugs.openjdk.java.net/browse/JDK-8140400
            Hide
            ostuart Owen Stuart added a comment -
            fix in CPU so no BPR needed
            Show
            ostuart Owen Stuart added a comment - fix in CPU so no BPR needed
            Hide
            herrick Andy Herrick added a comment -
            this was a test for something else that happened to show this problem.
            in your trace file:
            network: Cache entry found [url: http://oklahoma.us.oracle.com/www/tests/manifest/TestDeploy.jar, version: null]
            shows it accessed TestDeploy.jar - which it shouldn't since it is not listed in the jnlp (only in the ClassPath manifest attribute which should be ignored.)
            so that makes sense - 8u92 without fix shows the bug.
            what happens after that is not expected to work since it is copy of test for other fix that was not in 8u92 either.
            Show
            herrick Andy Herrick added a comment - this was a test for something else that happened to show this problem. in your trace file: network: Cache entry found [url: http://oklahoma.us.oracle.com/www/tests/manifest/TestDeploy.jar, version: null] shows it accessed TestDeploy.jar - which it shouldn't since it is not listed in the jnlp (only in the ClassPath manifest attribute which should be ignored.) so that makes sense - 8u92 without fix shows the bug. what happens after that is not expected to work since it is copy of test for other fix that was not in 8u92 either.
            Hide
            wenjyang Crystal Yang added a comment -
            Verified with jre9-b178 on win10/x64
            Show
            wenjyang Crystal Yang added a comment - Verified with jre9-b178 on win10/x64

              People

              • Assignee:
                mcherkas Mikhail Cherkasov (Inactive)
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: