[RFC][icedtea-web] Launch errors are not being printed to terminal.

[Danesh Dadachanji]

On 12/03/12 11:14 AM, Omair Majid wrote:
> On 03/12/2012 11:07 AM, Danesh Dadachanji wrote:
>> On 12/03/12 04:23 AM, Jiri Vanek wrote:
>>> On 03/11/2012 06:01 AM, Omair Majid wrote:
>>>> On 03/09/2012 12:16 PM, Danesh Dadachanji wrote:
>>>>> If javaws is run with -headless and a launch error occurs, no
>>>>> message is
>>>>> printed and javaws exits.
>>>>
>>>> By no message do you mean nothing at all (or is a single line message
>>>> printed without an exception stack trace)?
>>>>
>>>>> An exception is only shown if -verbose is
>>>>> passed too. This patch fixes it so that if -headless OR -verbose is
>>>>> used, the error and stacktrace are shown.
>>>>>
>>>>> Furthermore, when javaws -verbose is used (_without_ -headless), the
>>>>> stacktrace is printed to stderr too. This will come in handy once GUI
>>>>> testing for applets is available.
>>>>
>>>> I am not sure how. Applets don't use GuiLaunchHandler.
>>
>> They do from what I can tell. The handler is set to a
>> DefaultLaunchHandler if -headless is passed, otherwise to
>> GuiLaunchHandler - see JNLPRuntime.initialize(). From here, I can see a
>> number of methods calling Launcher.launchError() which calls the
>> handler's launchError(), the method I've modified. For example,
>> Launcher.createApplet() does.
>>
>
> Hm.... I guess you mean applet as in through javaws? /me was thinking of
> applets as in plugin.
>

Yep, this is only regarding javaws. As you mentioned below, the plugin 
doesn't send dialog prompts at all.

> See plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java
>
>          if (System.getSecurityManager() == null) {
>              JNLPRuntime.initialize(/* isApplication */false);
>              JNLPRuntime.setDefaultLaunchHandler(new DefaultLaunchHandler());
>          }
>
> If it wasn't being set, that would be a bug. We don't want to show
> prompts to the user for every applet that is running in the browser.
>
>>> I guess he have been thinking about gui tests at all. There will be gui
>>> tests also for javaws launches and in this case this become handy.
>>> For applets inside browser this should be solved in new spalshscreen.
>>> Also it is not possible to lunch applets inside browser headless.
>>> Also javaws -headless someAppelt is not working curently - the gui is
>>> still shown. There is a bug for it.
>>
>> Yes, the only reason I added this was for our test suite. The scenario I
>> had in my head was that an applet is run with GUI (i.e. javaws _without_
>> -headless) and may or may not throw an exception. It would be easier to
>> parse this from stderr rather than going through the dialog.
>
> I was thinking in terms of the user. Is it better to show the user
> entire stack traces rather than a single-line error message? I agree
> that with -verbose, stack traces should be printed. But even without?
>

I mentioned this in the other email...seems like this one got through 
first even though it was sent after!

 > Don't think I mentioned this in the original email but the reason behind
 > -headless or -verbose printing a stack trace is to make it similar to
 > when neither are passed. In this case, javaws prints the dialog with a
 > stack trace so in order to make -headless act similarly, Jiri and I
 > concluded it would be best to print the entire stacktrace if just
 > -headless was passed (regardless of -verbose).

Now whether we want this is a different thing, I think consistency is 
better but if it's more messy, I don't mind changing this. Either way, 
the one-liner's printed.

Cheers,
Danesh