JDK-6663089 : Issues with system property and JVM command-line argument specification to applets via JNLP
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-14
  • Updated: 2010-09-08
  • Resolved: 2008-03-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 b13Fixed
Related Reports
Duplicate :  
JDK-6649742 - Some of the system Plug-in properties are missing from the new Plug-in
Relates :  
JDK-6663557 - JRE version selection not working for applets launched via JNLP
Relates :  
JDK-6662404 - JNLP applet support does not re-launch for system property or command line argument specification
Description
This is a follow-on bug for the work done for re-launching an applet specified via JNLP in 6662404. Issues that need to be fixed:

 - If system properties are specified in the JNLP file, and the same applet is visited multiple times, multiple JVM instances are being launched because apparently we are unable to detect that a previously-launched JVM instance satisfies the new applet's command-line argument request.

 - Passing arbitrary JVM command-line arguments is not currently working.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6663089.1
14-02-2008
EVALUATION Changed how JNLP-launched applets both detect the need for a relaunch due to mismatched command-line arguments, and pass command-line argument requests back to the browser during relaunches. Now, instead of adding any additional system properties to the command line, they are simply added to the parameter map in the StartAppletMessage as the java_arguments parameter. This allows the existing browser-side code to work unmodified. Issues like multiple JVM instances being spawned for multiple runs of the same JNLP applet are transparently fixed with this change. The current JVM's command-line arguments are passed to the JNLP2Manager via a JVMParameters object directly from PluginMain. The preexisting mechanism for passing these command-line arguments from the browser side to the client JVM, which was previously necessary to determine whether the client JVM instance was secure, is reused. The use of the JnlpxArgs class in the new plug-in was eliminated. It is not applicable in its current form. The system property javaplugin.vm.options was added, mainly as an aid for testing. Permission was granted to read this system property from unsigned applets, though this may need to be changed in the future. The appletJRERelaunch method on Applet2Listener was changed to remove the JREDesc argument and to instead take the requested Java version as a String. The -Xmx and -Xms parameters are fabricated as command-line arguments within the JNLP2Manager during the relaunch process to hide complexity and reduce the number of places in the code that need to know about the JREDesc class. This work uncovered several preexisting bugs in the new plug-in, such as the JVMParameters class losing the -Xmx specification when serialized from the server to the client side. Other refactorings such as the introduction of the ArgUtil class and a renaming of the PropertyNames class to ParameterNames were also done. Javadoc in the JREDesc class was corrected. Some minor cleanups to tests written by ###@###.### were also made. More work is needed. JRE version selection via JNLP files is not yet implemented. The notion of the JRE's path, and matches against it in the JNLP2Manager's launch mechanism, needs to be completely eliminated. Auto-download support is also not yet implemented.
14-02-2008