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

[Jiri Vanek]

On 03/12/2012 04:14 PM, 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.
>
> 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?

It was me who suggested this. After reading this paragraph it looks like you are correct.
My opinion come from precedes,  that during NOT headless session, user receive WHOLE stacktrace in error dialogue. Thats why I wanted to show the whole stacktrace in headless mode.
 From your  paragraph opinion --verbose looks like button >>more<< in NOT headless mode.
What I have also on my mind is, that when user fill bug, then mostly first thing by which we are replying to him is something like  "can you run it with verbose and in debug mode"?

Now I'm 50/50 :)

>
> Cheers,
> Omair