JDK-8049056 : Deployment .jar files are missing in JAVA_HOME\lib, when installer calls RegisterDeployEx() from deploy.dll
  • Type: Bug
  • Component: install
  • Affected Version: 8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2014-07-02
  • Updated: 2015-02-12
  • Resolved: 2014-07-08
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 8 JDK 9
8u20Fixed 9 b26Fixed
Related Reports
Duplicate :  
JDK-8048860 - Windows register deploy introduces issues with static downgraded scenario
Duplicate :  
JDK-8049518 - Security Level are not Very High after reinstalling JRE with "WEB_JAVA_SECURITY_LEVEL=VH"
Relates :  
JDK-8073106 - Some dlls(jp2ssv.dll, ssv.dll, dtplugin\npdeployJava1.dll) are not copied to JAVA_HOME/bin before the moment when RegisterDeployEx() is called by the installer
Description
Looks like it's caused by JDK-8038734. During deployment registration process, we need to use deploy.jar for the following actions:
-setSecurityLevel
-getSecurityLevel
-getUserWebJavaStatus
-getUserPreviousDecisionsExist
-clearUserPreviousDecisions
-resetUserPreviousDecisionsDate
and when adding new deployment property.

Also, we verify plugin home dir by checking that plugin.jar exists in the directory. Probably, there are more functions that require these .jar files (deploy.jar, plugin.jar, javaws.jar) during installation process.
Currently I have 2 bugs that are caused by this ussue: JDK-8046923 and JDK-8041333, you can find details in the comments. I suppose there are more such bugs, so I guess we still need to copy the .jar files before calling RegisterDeployEx().

Affected cases:
MSI/MSI008-005-M 
MSI/MSI008-005-M-64 
MSI/MSI008-005-H 
MSI/MSI008-005-H-64 
MSI/MSI008-005-VH 
MSI/MSI008-005-VH-64 
MSI/MSI008-007-Lowest 
MSI/MSI008-007-Lowest-64 
MSI/MSI008-007-Highest 
MSI/MSI008-007-Highest-64 
MSI/MSI008-008-Lowest 
MSI/MSI008-008-Lowest-64 
MSI/MSI008-008-Highest 
MSI/MSI008-008-Highest-64 
MSI/MSI008-009-001-Enable 
MSI/MSI008-011-001-Lowest 
MSI/MSI008-011-001-Lowest-64 
MSI/MSI008-011-001-Highest 
MSI/MSI008-011-001-Highest-64 
MSI/MSI008-011-002-Lowest 
MSI/MSI008-011-002-Lowest-64 
MSI/MSI008-011-002-Highest 
MSI/MSI008-011-002-Highest-64 
MSI/MSI008-012-Lowest 
MSI/MSI008-012-Lowest-64 
MSI/MSI008-012-Highest 
MSI/MSI008-012-Highest-64 
MSI/MSI009-001-Enable 
MSI/MSI009-001-Enable-64 
MSI/MSI009-001-Disable 
MSI/MSI009-001-Disable-64 
MSI/MSI009-002-Enable 
MSI/MSI009-002-Enable-64 
MSI/MSI009-002-Disable 
MSI/MSI009-002-Disable-64 
MSI/MSI009-003-qn-Enable 
MSI/MSI009-003-qn-Enable-64 
MSI/MSI009-003-qn-Disable 
MSI/MSI009-003-qn-Disable-64 
MSI/MSI017-003 
MSI/MSI017-003-64
MSI/MSI007-002-FF
MSI/MSI007-002-IE
MSI/MSI007-004-FF
MSI/MSI007-004-IE
MSI/MSI007-002-IE-64
MSI/MSI007-004-IE-64
MSI/MSI008-009-001-Disable-64
MSI/MSI008-009-001-Enable-64
MSI/MSI008-009-002-Disable-64
MSI/MSI008-009-002-Enable-64
Comments
Verified with 9 b27
28-08-2014
PIT verified with JDK 9 b26
28-07-2014
Affected tests: LSPOldJREInstalledTest::testAdminWith17Star_DevWith18Star_High LSPOldJREInstalledTest::testAdminWith17Star_DevWith18Star_VeryHigh
22-07-2014
Additional affected tests: JreTests/JRE013-006-iftw-HighestNull JreTests/JRE013-011-Offline-LevelHighestReinstall JreTests/JRE013-011-iftw-LevelHighestReinstall
10-07-2014
SQE OK with fixing in 8u20.
08-07-2014
justification: deployment registration broken without this fix. This is a must fix for 8u20. crucible: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-383
08-07-2014
Affected tests(from JDK-8041333): JreTests/JRE013-004-Offline-LevelHighest JreTests/JRE013-004-Offline-LevelHighest-64 JreTests/JRE013-004-iftw-LevelHighest JreTests/JRE013-005-Offline-LowestHighest-7u21andup JreTests/JRE013-005-iftw-LowestHighest-7u21andup JreTests/JRE013-006-Offline-HighestNull JreTests/JRE013-006-Offline-HighestNull-64 JreTests/JRE013-006-Offline-LowestNull-7u21andup JreTests/JRE013-006-iftw-LowestNull-7u21andup JreTests/JRE013-007-Offline-DisabledHighestLowest-7u21andup JreTests/JRE013-007-Offline-DisabledLowestHighest-7u21andup JreTests/JRE013-007-iftw-DisabledHighestLowest-7u21andup JreTests/JRE013-007-iftw-DisabledLowestHighest-7u21andup JreTests/JRE013-009-Offline-LevelHighestPIP JreTests/JRE013-009-iftw-LevelHighestPIP JreTests/JRE013-011-Offline-LevelHighestReinstall-64 JreTests/JRE013-014-Offline-DisabledFamilyNewOld-64 JreTests/JRE013-014-Offline-DisabledFamilyOldNew-64 JreTests/JRE013-015-Offline-HighestFamilyNewOld JreTests/JRE013-015-Offline-HighestFamilyNewOld-64 JreTests/JRE013-015-Offline-LowestFamilyNewOld-7u21andup JreTests/JRE013-015-iftw-HighestFamilyNewOld JreTests/JRE013-015-iftw-LowestFamilyNewOld-7u21andup JreTests/JRE013-021-iftw-LevelHighest JreTests/JRE013-021-iftw-LevelLowest-7u21andup JreTests/JRE013-021-iftw-LevelLowest-7u21andup JreTests/JRE013-021-offline-LevelLowest-7u21andup JreTests/JRE013-021-offline-LevelHighest
08-07-2014
Fix is in-progress for 8u40. Due date for 8u20 backport/critical-request 7/8.
03-07-2014
affected testlist: MSI/MSI007-001-qb-IE-64 MSI/MSI007-001-qn-IE-64 MSI/MSI007-003-IE-64
02-07-2014
There are 2 possible fixes to this one: Solution 1. Add the unpack200 calls back to installer.exe, and only call the new standalone unpack custom actions during repair mode. This is low risk, but involves the duplication of unpacking the jar files in 2 different ways (via installer.exe and stand-alone custom action calls) OR Solution 2. Remove the stand-alone unpack custom actions, and introduce a new repair mode/arg for installer.exe. This is more work and a little messy, but has other advantages such as having everything in one place in the installer.exe.
02-07-2014
This was introduced by the recent msi repair feature work. We took the unpacking out of installer.exe, so that it can be called by custom actions during repair mode. Unpacking must get called after installer.exe gets run, because installer.exe does the extraction/patching first. But RegisterDeploy is getting called before unpack200 gets run on deploy.jar, so that's the issue.
02-07-2014