United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6665008 Auto-download support is not present for applets launched via JNLP
JDK-6665008 : Auto-download support is not present for applets launched via JNLP

Details
Type:
Bug
Submit Date:
2008-02-19
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-06-25
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b21)

Related Reports
Relates:
Relates:

Sub Tasks

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
EVALUATION

Enabling client side JRE download and install.
Passing info on installed JRE's from server to client.
                                     
2008-02-20
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
                                     
2008-02-26



Hardware and Software, Engineered to Work Together