A- The bug is in the very old 7u2 installer code baseline.
B- The bug is only triggered on a corner case: downgrading to the old 7u2.
C- There is a valid workaround: to uninstall 7u10 and reinstall it again.
Because of A/B/C, closing as won't fix.
|
|
|
Requesting deferral from 7u10 based on rationale outlined by Bill, above.
|
|
|
bug is probably in 7u2 installer code - it does not handle the case where the deploy minor version has 2 digits or more. also, I don't think 7u2 installer code is using registerDeploy API yet.
I think this is a corner case (downgrade install to very old version), and should be documented and closed.
|
|
|
Looks like a bug in 7u2 code:
7u10 b15 installed, then 7u2 installed - applets don't work
7u10 b15 installed, then 7u4 installed - applets work
|
|
|
I was able to reproduce with 64-bit JRE's, but not with 32-bit JRE's.
I was also able to reproduce with installing 7u2 into the default location (not overriding it like the reproducible steps say to).
|
|
|
One difference I noticed between the 32-bit vs 64-bit experience is that I got an extra prompt for running the ssvagent.exe with the 64-bit experience, but not with the 32-bit experience. Not sure why that's happening, but I'm going to try again.
I'm also installing Active Registry Monitor to see what 7u2 registries could be messing up the plugin.
|
|
|
I'm now seeing this with both 32-bit and 64-bit. I think my 32-bit plugin registry was corrupt before for some other reason (dirty machine). It seems the same issue is happening for both 32-bit and 64-bit now.
Installing 7u10 creates this key:
Java Plug-in
10.10.2
Then installing 7u2 creates this key:
Java Plug-in
10.2.0
It seems like 7u2 will register 10.2.0 as the latest, which is incorrect. It also disables the UseJava2Explorer key, which turns off the plugin. Turning this key back to 1 will get the applet to load properly. But that's still not correct because 7u10 should be registered as the plugin.
|
|
|
Workaround is to uninstall 7u10 and reinstall it again. This seems to tell me that the latest deploy code correctly recognizes that 10.10 is newer than 10.2.
|
|
|
Well, it could be bug in 7u2 code. Can the same problem be reproduced with 7u4 or 7u6 instead of 7u2?
Even if it is 7/7u1/7u2/7u3-only it might be possible to fool 7u2 by doing something special in 7u10 but this will be lower priority.
|
|
|
One possibility is that the new deployment registration is recognizing 10.2.0 as a higher version than 10.10.2. When comparing versions, my guess is that "2" (1.7.0_02) is calculating higher then "10" (1.7.0_10).
How to proceed forward:
-We need deployment guys to tell us if my analysis is true
-We need the deployment guys to tell us if this is still a problem with the current deployment registration code in deploy.dll. Will it incorrectly detect that 10.2.* is newer than 10.10.*? Or was this just an issue with the old 7u2 code that lived in installer.dll
|
|
|
SQE comment - this is not a common scenario that 7u2 is installed after 7u10 - it can be deferred to 7u12
|
|
|
Bill, pls triage. Ideally all the registration/unregistration elements should be completely encapsulated within the regdeploy library. Pls make sure that whaever the correction is (if it involves install code) is addressed that manner.
GGG
|
|
|
Ideally all the registration elements should be fully encapsulated within the redeploy library. If this is a installer issue let's try to provide a correction following the previous guiding principle.
|
|
|
The problem is reproduced with 7u10 b12
Yes, this is a deploy issue - changing component.
|
|
|
The forest used to build 7u10 b06 is now targeted to 7u12. Does this still happen in 7u10 b12? Or should this be moved to 7u12?
And is the an install or deploy issue?
|
|
|
Affected test:
SSV2Test::testBaselineVersionsInsecureJREUnSigned
|
|
|
Java