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

      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

            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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: