[rfc][icedtea-web] finish to get rid of std out/err in testsuites

[Adam Domurad]

Reapplying your (updated) patch, I do not get the test error anymore,
and my test failure rate is more or less back to normal (24 reproducers
failing, which I still must get to the root cause of.) 

Patch looks OK to me otherwise, and as you said this patch will be of
help with the failing applets you get on F17, OK for HEAD from me,
although any of the autotools stuff would be beyond my ability to
review.

On Mon, 2012-06-11 at 17:27 +0200, Jiri Vanek wrote:
> On 06/07/2012 09:01 PM, Adam Domurad wrote:
> > Sounds like a good idea.
> > The information log lay out looks nice to me.
> >
> > (Small comment on logXXXReprint, although not part of this patch, the
> > 'Reprint' idea was a bit unclear to me about what constituted the
> > reprinting - my favour is to something like logXXXAndPrintln but take
> > the suggestion as you will.)
> >
> > This patch seems to break some tests - eg ReadEnvironmentTest no longer
> > seems to have the same contents of pr.stderr and thus fails, instead of
> > containing the security related exception it has:
> > netx: Launch Error: Could not launch JNLP file. ( ())
> > net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file.
> > 	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:600)
> > 	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889)
> > Caused by: java.lang.reflect.InvocationTargetException
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 	at java.lang.reflect.Method.invoke(Method.java:601)
> > (etc...)
> >
> > Are you experiencing this as well ?
> >
> >
> > Some minor comments (nitpicks if you will) inline.
> 
> HI!
> Thanx for review, all you have told should be fixed now.
> 
> Except OutputStreamWriter - I kept it inside without buffering, as I want to have as few buffers as 
> possible on the way out. They can consume something in case of failure too. (one of the suspicious 
> for erros you see in applets perhaps? - the reader are buffered)
> 
> Also the exception you are mentioning above - i really did not experienced it! Have run the tests 
> today once more and everything was ok.... But still I must admit there is bug somewhere :-/
> 
> Attached is fixed patch. Changelog will remains same.
> 
> Tahnx again for review!
> J.