JDK-6673621 : Can not launch Bugster with current nightly build
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2008-03-11
  • Updated: 2010-09-17
  • Resolved: 2008-06-19
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 JDK 7
6u10 b21Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6674717 - More exceptions thrown on the client side
Relates :  
JDK-6668033 - New plugin applet freezes the browser occasionally
Description
It appears that the changes to the quoting rules that were part of the putback for 6668033 have broken the Bugster application on Windows. Bugster specifies a system property whose value is a quoted string with spaces in it and it appears that one of the words in this string is being misconstrued as the main class.

src/share/bin/java.c in the j2se workspace was modified (see the attached file) to print out the main class in its error message. The output is

    Could not find the main class: query. Program will exit.

If http://bugster.central.sun.com/bugster.jnlp is saved to the local disk and examined, one can see that the value for the system property "QueryResult.WarningMessage" contains the string "query".

The debugging techniques used to track this down were:

  - Modifying java.c as above.
  - Setting the environment variable JAVAWS_TRACE_NATIVE to 1.
  - Turning on tracing and logging in the Java Control Panel, and setting deployment.trace.level=all in C:\Documents and Settings\username\Application Data\Sun\Java\Deployment\deployment.properties .

Then bugster.jnlp was saved to the local disk and executed. For some reason, running javaws.exe against http://bugster.sfbay.sun.com/bugster.jnlp does not reproduce the problem.

The logs in C:\Documents and Settings\username\Application Data\Sun\Java\Deployment\log\ (javaws*.trace) were examined. Toward the end of the log one can see the values for various command line arguments, in particular jnlpx.vmargs, which is hypothesized to be the problem argument.
Comments
SUGGESTED FIX 6673621 : Can not launch Bugster with current nightly build [Andy Herrick, Kenneth Russell] - CR 6674717 - More exceptions thrown on the client side Without CRs: - JNLP2Manager getCode() regression - JNLP insecure arguments and relaunch +++ 6673621 : Can not launch Bugster with current nightly build [Kenneth Russell, Thomas Ng] The Windows j2se Process parseImpl is different from the Unix one. It is expected to have quoted values like: "-Dlala=c:\la la\lala.exe" instead of -Dlala="c:\la la\lala.exe" which is valid for the Unix variant. We have to workaround this j2se bug, therefor we quote os dependent in Property, where we use the result for relaunch. Internally we always use the Unix variant. - For commandline assembling (i.e. relaunch), the Property quoting will be done depending on the OS, i.e. Windows: "-Dlala=c:\la la\lala.exe", Unix: -Dlala="c:\la la\lala.exe" See: Property.toString(boolean osConform). The property jvm-args, will be unified. - unquoting will be done at JVMParameters's parse() and addArgument() method, and at Property construction. - Property is now a standalone class - extracted from JVMParameters - Module tests have been adapted StringQuoteUtil: - removed '\\' from quote criterias - unquoteIfEnclosedInQuotes() truly verifies if the argument is one quoted atom - quoteIfNeeded() only quotes, if the unquoted part of the argument needs to be quoted - getCommandLineArgs() fixed, - argument may start with a quote - resulting argument list is unquoted - getStringByCommandList() may quoted single arguments if needed +++ 6674717 - More exceptions thrown on the client side Only print informal exception about a wrong mapped manager, if it's not null. +++ JNLP2Manager getCode() regression - getCode() consider non initialization and non applet's +++ JNLP insecure arguments and relaunch - IF ( not-a-relaunch && no-match && args.isSecure && ld.isSecure) THEN relaunch(secureArgsOnly(all-args)) allSigned=LaunchDownload.checkSignedResources() // the following decision and action (2 lines) are done in checkSignedResources() if(!ls.isSecure && !allSigned) THEN throw SecurityException IF ( not-a-relaunch && no-match ) THEN relaunch(allSigned?all-args:secureArgsOnly(all-args)) LaunchDesc - Reverted the isSecure to the SANDBOX model alone - Added direct accessor to the selectedJVMParams.isSecure(): isSecureJVMArgs() LaunchDownload.checkSignedResources() - Reverted: SecurityException only if !allSigned && !SANDBOX - Added: IF !isSecureJVMArgs() THEN visit all resources and return allSigned - the difference to !SANDBOX is, that no exception is thrown and the allSigned is returned - whether all JARs are signed or not. Launcher/JNLP2Manager: - Insecure arguments will be used only is all JARs are signed, else only the secure arguments ResourceDesc - preserving the order of properties, while using the OrderedHashList for collecting Properties JnlpxArgs: - Add an extra relaunch property 'jnlpx.relaunch=true', to determine a relaunch session. +++ testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6673621/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6673621.1 workspace: deploy engineer: sven.gothel
13-03-2008
EVALUATION The Windows j2se parseImpl is different from the Unix one. It is expected to have quoted values like: "-Dlala=c:\la la\lala.exe" instead of -Dlala="c:\la la\lala.exe" The StringQuoteUtil and JVMParamters.Property will change to meet these requirements.
12-03-2008