United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6718336 kernel jre uninstallation interrupted with java setup - close applications dialog
JDK-6718336 : kernel jre uninstallation interrupted with java setup - close applications dialog

Details
Type:
Bug
Submit Date:
2008-06-24
Status:
Closed
Updated Date:
2010-04-06
Project Name:
JDK
Resolved Date:
2009-07-27
Component:
install
OS:
windows_xp,windows
Sub-Component:
install
CPU:
x86
Priority:
P3
Resolution:
Duplicate
Affected Versions:
6u10
Fixed Versions:
6-pool

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
Kernel jre  uninstallation interrupted with java setup - close applications dialog

Tested build : 6u10 b27 PIT
Tested OS : Win XP

Steps to reproduce:
1. install kernel bundle
2. once the installation is completed, try to uninstall the jre
"Java Setup - Close Applications" dialog popsup asking to close "java.exe" with retry and cancel buttons
Background downloader is still running and it is not getting killed automatically. When retry button is clicked by checking the checkbox "quit the applications listed", it proceeded with uninstallation.

It is a regression from b26. Image file attached.

                                    

Comments
EVALUATION

It seems that adding the FilesInUseDialog CustomAction to the InstallExecuteSequence is creating a regression:

6718336: kernel jre  uninstallation interrupted with java setup - close applications dialog
   -this is because FilesInUseDialog is getting called before UninstallJRE can shutdown the background downloader

I think we need to call FilesInUseDialog CustomAction before both UninstallJRE and UnInstallJUpdate Custom Actions.
                                     
2008-06-24
EVALUATION

I think Bill intended to say we need to call our Files-In-Use custom action *after* the other custom actions above.

Please also see CR 6674868...we initially called our own FIU (custom action) as a workaround to the difficiencies of the MSI native version.

The native version is invoked in InstallValidate in the InstallExecute sequence. We needed to call our own before InstallValidate in order to avoid the native version.

To address the issue of this CR, we'll need to move our own FIU to a point in the InstallExecute sequence that is *after* InstallValidate. This will increase the likelihood that MSI's native version of the dialog will be invoked, but that's ok. Here's why...

The native version of the dialog will not catch java[w].exe or jbroker.exe because there is no associated window with these processes. This is one of the downfalls of the native dialog that prompted us to create our own version in the first place. Therefore, we will not need to remove java[w].exe or jbroker.exe from the RemoveFile table...they will not cause the native dialog to be invoked.

In considering 6674868, any problems associated with the native version of the dialog will STILL be handled when our 'custom' version is invoked. For example, if the user clicks 'ignore', that's ok because our FIU will be invoked later and handle any processes that are still locking the JRE.

The ONLY downside to this fix is that there is potential for 2 "files-in-use" dialogs being displayed. In my opinion this is also ok because the potential for that is very low (user would need to click on 'ignore', or start more java procs after the MSI version is invoked).

Generating a webrev now for moving the Files-In-Use custom action down the InstallExecute sequence...
                                     
2008-08-22
EVALUATION

putback to the integration ws is complete for b01.
                                     
2008-10-23



Hardware and Software, Engineered to Work Together