[rfc][icedtea-web] closing listener idea

[Adam Domurad]

On Fri, 2012-08-17 at 12:19 +0200, Jiri Vanek wrote:
> On 08/15/2012 06:57 PM, Jiri Vanek wrote:
> > On 08/14/2012 05:50 PM, Adam Domurad wrote:
> >> On Tue, 2012-08-14 at 17:06 +0200, Jiri Vanek wrote:
> >>> This idea should speed up browser tests a lot. When all conditions for pass/failure are done,
> >>> browser is terminated and is not waiting for time-out any more.
> >>> It is bringing some more load to tester, but its usage is mandatory.
> >> Thanks very much for the ideas!
> >>
> >> It would have been nice if it were like this from the beginning - but
> >> nevertheless this would be a great improvement.
> >>
> >> I'm 100% for converting all tests to this form, and mandating it for
> >> future applet tests. I'm sure as the most frequent runner of the test
> >> suite you can agree, at least for mandating it for future tests :)
> >
> > Definitely! I will need some helpt to get it to tests in head ;)
> >>
> >>>
> >>> Usage here is demonstrated on simple applet test.
> >>> Any ideas (especially how to avoid doubled "contains" or "matches") welcomed.
> >>>
> >>> J.
> >>>
> >>> * tests/reproducers/simple/AppletTest/testcases/AppletTestTests.java: Integrated ClosingListener
> >>> speed-up.
> >>> * tests/test-extensions/net/sourceforge/jnlp/ClosingListener.java: New file, interface for all
> >>> ClosingListeners.
> >>> * tests/test-extensions/net/sourceforge/jnlp/CountingClosingListener.java: Implementation of
> >>> ClsoingListeners which is storing copy of complete output of program.
> >>> * tests/test-extensions/net/sourceforge/jnlp/ProcessAssasin.java: added (setTimeout) method as
> >>> cleanest possibility to terminate process immediately
> >>> * tests/test-extensions/net/sourceforge/jnlp/ServerAccess.java: new method (setUpClosingListener)
> >>> for setting necessary variables in ClosingListener
> >>
> >> This method is nice enough, although is it possible to have a
> >> standardized way to see if an exception has caused the applet to stop ?
> >>
> >> I'm very much in favour of adding a clear end marker to the end of tests
> >> rather than duplicating contains/matches. If you don't like a hardcoded
> >> ending message, then, what if we had a closing listener implementation
> >> that takes a single string as an argument, and a string is printed at
> >> the end of the applet. Custom closing listeners could always also be
> >> created.
> >>
> >
> > I'm little bit against using such a constants (which must be copy pasted into reproducer to complete
> > the evil ) but I admit it canhel a lot. But I would recommend to be careful with such a simple
> > "terminator" - as exception can be thrown "later".
> >
> > Anyway some idea how to integrate this is in this updated patch.
> >
> > I have posted also one more idea to patch, and although it eliminates duplicity, it have quite a lot
> > of code :-/.
> >
> > Both new apporaches shown in AppletTestSigned
> >
> > thanx for discussion,
> >
> > J.
> >
> >
> > Ps - I have not tested this new code due to lack of time today so be patient with it. I will do in
> > friday. I'm posting it for you to get the feedback for more ideas!
> 
> No ideas ? Never mind - debugged version of above attached There was serious error in listeners 
I had ideas, I had to think them through though :)
I don't know if I like the verbosity here. Creating a contains-rule for
everything separately and then combining them into an array of rules
seems like a lot to simply close the browser at the right time. 

Better would be something like:
RuleSet passingRules = new RuleSet().contains(str1, str2).matches(str3,
str4);
RuleSet failingRules = new RuleSet().contains(str5, str6).matches(str7,
str8);
But I'm still not sure. It would be much more ideal if the applet simply
signal when it is completed somehow, independent of the validation
rules. I think simply checking for an ***APPLET FINISHED*** message that
was standard for all tests is a good-enough solution. It will cause all
well-behaving applets to speed up, which should be at least the majority
of them. It could also be nice to have some components common to all
applets, (eg common patterns such as Killer thread), that way we could
have something like TestAppletsUtil.printFinishedMessage();

> (also was caused your listeners in previous reproducer not working). It is included here but I'm 
> going to fix this separately.
> 
> 
> J.
>