[rfc][icedtea-web] closing listener idea

[Jiri Vanek]

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 
(also was caused your listeners in previous reproducer not working). It is included here but I'm 
going to fix this separately.


J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: closingListener_3.diff
Type: text/x-patch
Size: 41573 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120817/1a3e4a1e/closingListener_3.diff