JDK-8155076 : Webstart loads JARs from MANIFEST.MF after loading the jars from resources-tag
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u91,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2016-04-20
  • Updated: 2017-11-14
  • Resolved: 2016-05-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u111Fixed 8u101Fixed 9 b124Fixed
Related Reports
Duplicate :  
JDK-8155226 - JNLPClassLoader/DeployURLClassPath with Java Web Start (11.91.2.14) are not using local jar cache
Duplicate :  
JDK-8155706 - JWS download classes from the network server instead of using cached jar files
Duplicate :  
JDK-8159453 - Security settings block an untrusted application from running in 7u101
Duplicate :  
JDK-8157445 - Javawebstart loads jars from MANIFEST
Relates :  
JDK-8163845 - CachedJarFile.getManifest throws UnsupportedOperationException (Collections$UnmodifiableMap.remove)
Relates :  
JDK-8155809 - Launching application with dependencies via Java Web Start is much slower since 1.8.0_77
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 .
Comments
Verified with jre9-b178 on win10/x64
21-07-2017
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.
28-06-2016
fix in CPU so no BPR needed
20-06-2016
Regression was caused by https://bugs.openjdk.java.net/browse/JDK-8140400
07-06-2016
No nightly issues related to the fix in the Deployment nightly. UR SQE OK to take it in CPU16_03
06-06-2016
review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1998
25-05-2016
[~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.
24-05-2016
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.
24-05-2016
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.
12-05-2016
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)
29-04-2016
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 =================================================================
29-04-2016