[RFC][icedtea-web] Fix for single instance service with applets using jnlp_href

[Jiri Vanek]

>>
>
> Yeah, it was a confusing service to wrap my head around. :S
>
> Right now, SingleInstanceService is available to use from applets/applications run by javaws. I am
> trying to port this over to the plugin so that when jnlp_href is used, applets have access to it.
>
> The point of the service itself is to only let one instance of an applet run at a time. There's a
> catch to running another instance of the applet though. While the first one is running, it is setup
> with a listener for later instances to use. The idea is that the second instance can communicate
> with the running instance, passing along some args to be handled by the listener, and then exit.
> When you run another instance of the applet, icedtea-web is supposed to recognize this as the second
> instance and pass on a list of arguments provided by the dev. See the API for
> SingleInstanceListener[1] for the methods. I think the following signleapp example[2] might help you
> too.
>
> Here's an example run path:
>
> 1. Start single instance app. The dev has set it up to handle params accordingly, say to spit it out
> on the screen to log.
> 2. IcedTea-Web sets up a single instance server to keep track of the instance running.
> 3. The second app is run, args are passed in by the dev again. Let's say they are the current
> date/time.
> 4. IcedTea-Web notices the second app is a second instance of the first one and checks that the
> first one's server is still running, then denies init of the second applet. The second instance's
> args are taken and passed along to the first instance's newActivation(String[] args) method.
> 5. Dev's newActivation method reacts accordingly.
>
> I hope the example[2] helps clear up any doubts I have not covered but please ask if it doesn't!
>
>>> Attached is a patch to fix SingleInstanceService to work when applets
>>> use jnlp_href.
>>>
>>> If a single instance exists, it'll throw a fatal exception for the
>>> second applet and stop running it. The applet passes the args along
>>> while checking. However, proprietary documentation is unclear about
>>> which args are passed so for now I have left it as a FIXME until
>>> that's cleared up.
>> I believe applets parameters inside tag/jnlp descriptor are correct way.
>
> These args I was referring to are from the second instance being run so we're talking about
> different things here. =) Please see above.
>
Well well... It was digging to find what this should be doing, and it looks tome like it is not 
doing something.

Can I ask for large set of reproducers?

two same javaws applications runnig together/ two same javaws applications running as SingleInstance 
and passing params / two different javaws  running together/ two different javaws applications 
running as SingleInstance and "passing" params

two same applets-in-javaws applications runig together/ two same applets-in-javaws applications 
running as SingleInstance and passing params / two different applets-in-javaws  running together/ 
two different applets-in-javaws applications running as SingleInstance and "passing" params

two same applets-in-browser  running together/ two same applets-in-javaws applications running as 
SingleInstance and passing params /two different applets-in-browser  running together/ two different 
applets-in-javaws applications running as SingleInstance and "passing" params



It will need similar approach as I have used in   xfork test, but better then sleep use StdOut use 
contentReader listeners and do not wait for timeout (as it really delays 	test runs)


The patch itself looks ok, and if will pass above tests, then it is ok for head. The only  issue is 
passing params to applet. Yes, specification is silent in this issue, but I'm against String[0] (at 
least it is hard to test!:)). My idea here is to pass new String{key1,value1, 
key2,value2...keyn,valuen}. Better then nothing I believe.

Thanx for hard work!
   J.