SUGGESTED FIX
Besides adding auto download support,
we made the plugin2 C/S protocol more bulletproof.
The testcases mentioned on the testcase page
cover all relaunch cases, in all combinations:
- jre version w/o auto-download
- jvm_args: properties
- jvm_args: max-heap size
- jvm_args: custom
We have verified the 'javaws' impact:
- no regressions detected
- control panel shows installed JRE's
Due to the lack of a instrumented browser,
and the fact, that our standalone viewer could not handle relaunch,
we cannot yet offer an automated test harness.
Sorry.
+++
JRE Auto-Download / Relaunch
JavaWS:
- LaunchSelection.selectJRE(), LaunchDescFactory, XMLFormat, LaunchDesc
Allowing to pass a custom 'MatchJREIf' interface,
like the following implementations:
- DefaultMatchJRE
The original one, used as default.
- sun.plugin2.applet.Plugin2MatchJRE
See below.
This optional customization using 'MatchJREIf'
is handles from 'LaunchDescFactory', to 'XMLFormat'
and 'LaunchDesc'.
Deploy:
- JVMParameters.ArgumentSet.addArgument()
Other arg starting with '-' still is an arg
and therefor returns true.
- JREInfo
- Adding '.args' to the properties/attributes,
so this information won't get lost,
while using JREInfo within plugin2 (see below).
This is backwards compatible, i.e. won't hurt core JAVAWS,
since it is not required.
- Now, JREInfo is being used in plugin2
- Using com.sun.deploy.config.NativePlatform
to hold the osname and osarch, as well as to compute
isOsInfoMatch.
- com.sun.deploy.config.NativePlatform (new)
holds osname, osarch and compute a unified osarch,
respecting the different known osarch strings of some vendors.
the compatible methods compares osname and the unified osarch,
so osarch like 'i386' and 'x86' would be a match.
- PluginJavaInfo:
- This class 'setInstalledJREList' and 'initialize
will create a JREInfo copy and store it in JREInfo's list.
- No more reference to this class from within plugin2.
- Respecting OSNAME and OSARCH in properties and
actually uses/stores them
- Keep in mind, this is considered a 'hack',
and we propose to get rid of 'PluginJavaInfo' at all
and consolidate all JRE's in JREInfo.
Biggest objection against PluginJavaInfo,
is it's propeties presentation,
which won't allow us to have the same JRE version
for different platforms.
Plugin2:
- Plugin2MatchJRE
Used by plugin2, to compare the version and vm-args,
same semantics as DefaultMatchJRE regarding version comparison.
But we use JVMParameter to make the args check
and require that the current JVM's arg contain all of our
desired arguments to have a complete match.
If the arguments does not satisfy, we consider the JRE match
to be valid for relaunch.
- JNLP2Manager
- Adding JRE download and installation
- Using 'Plugin2MatchJRE', which simplifies the whole relaunch case.
- JVMManager:
- processPluginJavaInfo() -> processJREInfo()
In the relaunch case, after the client has installed a new JRE,
JVMManager.relaunchApplet()'s will call
- Config.refreshProps() // to catch the new JRE
- processJREInfo() // to do the usual JREInfo processing
to refresh the property data.
- filterJavaPlatformList() filters out non matching osName and osArch,
using JREInfo.isOsInfoMatch()
+++
Browser/Client/Server Stability
- JVMInstance / PluginMain:
- Adding 'StartAppletAbortedMessage', which notifies the server,
that the applet failed to start.
This allows the server to act immediatly, i.e. unregister the applet
and gives us a well defined sequence of events where we can handle it.
Added missing start applet abortion in case of:
- no manager could be created
- createEmbeddedFrame failed, which was previosly using the listener model,
but no listener was registered yet
- PluginMain / Plugin2Manager
- Ensuring that at least 'StartAppletAbortedMessage' is send to the server,
in case that no other message has been send, or the applet is running well.
After starting an applet, the server _must_ receive one of the following messages:
fireAppletIsUnsigned()
Applet2Listener.appletIsUnsigned==false -> StartMessage
fireAppletJRERelaunch
Applet2Listener.appletJRERelaunch -> StartMessage
fireAppletReady()
Applet2Listener.appletReady -> JavaReplyMessage(ok)
fireAppletErrorOccurred()
Applet2Listener.appletErrorOccurred -> JavaReplyMessage(error) or
StartAppletAbortedMessage
Within Plugin2Manager's applet lifecycle AppletExecutionRunnable,
we ensure that if none of the above messages has been send,
a 'StartAppletAbortedMessage' will be issued.
The server will unregister the applet properly in any error cases.
This shall solve any browser/liveconnect deadlocks,
since we query for running applets.
Proper access qualifiers for the new setErrorOccured, etc methods.
- Plugin2Manager, Applet2Manager, JNLP2Manager
Consolidated 'createApplet'.
Both implementations were the same, so it is general and
moved to Plugin2Manager.
If createApplet returns null,
'setErrorOccured' is set in the AppletExecutionRunnable,
if no error state was set yet.
This shall ensure it will be done for sure.
Augmented the failure injection idea.
Using a static final aggregation initialization of one environment var,
which tokens are assigned to the static final injection boolean's
Current tested failures are:
JPI_PLUGIN2_INJECT_JNLP2MANAGER=
EXCEPTION_CSTR
EXCEPTION_INIT
EXCEPTION_LOADJARFILES
FOREVER_LOADJARFILES
JPI_PLUGIN2_INJECT_PLUGIN2MANAGER=
EXCEPTION_CREATEAPPLET
CREATEAPPLET_NULL
JPI_PLUGIN2_INJECT_PLUGINMAIN
HEARTBEAT_DROP_ALL_APPLETS
|
Java