JDK-6665008 : Auto-download support is not present for applets launched via JNLP
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-19
  • Updated: 2010-09-08
  • Resolved: 2008-06-25
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 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-6663557 - JRE version selection not working for applets launched via JNLP
Relates :  
JDK-6606784 - Add support for launching applets from JNLP files
Description
The support for launching applets from JNLP files introduced in 6606784 does not yet contain support for auto-download of the JRE. The version selection support added in 6663557 is currently very basic and needs to be enhanced with this functionality.
Comments
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
26-02-2008
EVALUATION Enabling client side JRE download and install. Passing info on installed JRE's from server to client.
20-02-2008