RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.

[Stuart Marks]

On 6/27/13 4:58 PM, Brad Wetmore wrote:
> Chris (and Michael),
>
> As my part of the "intermittently failing test cleanup," I'm looking into a
> test of yours that has been intermittently failing.
>
> It's bug:
>
>      https://jbs.oracle.com/bugs/browse/JDK-8017333

The open URL to view this bug is:

     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333

> which is failing the regression test you added for:
>
>      http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65
>
> You used a really old version of the test framework (pre-2003!) which doesn't
> output both the client and server exceptions.  I've updated the test to use the
> new framework, and would like to put this back as a temporary measure so we can
> see what is really happening from any possible swallowed exceptions.
>
> Xuelei/I are stumped as to what might be happening, so hopefully this action
> will give some clarity.
>
>      8019341: Update CookieHttpsClientTest to use the newer framework.
>
>      http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/

Improving the exception handling seems mostly reasonable.

It looks like startServer() and startClient() now both try to catch any 
exceptions and store them in variables for later processing. But they still are 
declared to throw Exception, and the code that calls them from the constructor 
throws away any exception that's caught there. Hm, it's hard to know what 
exception might be caught at that point, but since we don't really know what's 
going on, we probably shouldn't rule anything out.

Most places catch Exception. One possibility to consider is whether an Error of 
some type might be thrown, which isn't caught by "catch (Exception)" clauses.

In the place where you potentially have two exceptions to report, you might 
consider using the suppressed exception mechanism. This is bending the 
semantics a bit, but if the client is subordinate to the server (or vice versa) 
and both throw exceptions, only one can be propagated, so it could seem 
somewhat proper to consider one exception to have suppressed the other.

> It would be easiest to compare your test to the
> test/sun/security/ssl/templates/SSLSocketTemplate.java.  They should be the
> same except for your test-specific code.

Hm, a template-based framework? Might be worth investigating turning this into 
a library at some point.

> Brad
>
> P.S.  I think AlanB/JoeD/StuartM will appreciate this effort.  ;)

Yes, indeed. :-)

s'marks