JDK-7147659 : static version clsid used for treatas key should not be hard coded in ssv
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2012-02-22
  • Updated: 2013-11-05
  • Resolved: 2012-02-23
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.
7u4Fixed 8 b27Fixed
static version clsid used for treatas key should not be hard coded in ssv

see root cause:  http://javafx-jira.kenai.com/browse/RT-19735

EVALUATION problem: Currently when ssv sets treatas key, it uses the static version clsid based on the hard code ssv dll version. registerdeploy and jp2ssv both uses this to ensure the right treatas value. but this is not correct anymore, since now we ship deploy separately with FX runtime. So you can have 6uX + FX runtime (7u4 deploy). And we will still use clisd based on version 7u4, but the system does not have 7u4 JRE at all. this causes issues: http://javafx-jira.kenai.com/browse/RT-19735 fix: use static CLSID of latest installed JRE for treatas. It should not be based on the deploy version hardcoded in dll. this will solve the problem of rt-19735 where on XP, 6uX + FX doesn't work on IE. it's a regression we introduced in FX 2 b13. we need follow-up changes to solve other issues found while investigating this: 1. what's the right branch to register our CLSID ? HKLM ? HKCU ? HKCR ? right now our code is a bit of everything. jp2 uses HKCU/HKLM, ssv/dt uses HKCR. 2. create/install static CLSID versions based on installed JRE (not hardcode version string in dll) 3. any other places that might be using the hard coded CLSID in a wrong way: JPI_IEXPLORER_APPLET_CLSID testcase: manual test to check treatas key value is set right by both installer (registerdeploy) and jp2ssv.