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

[Brad Wetmore]

Michael wrote:

 > I'd agree with this. If the exception is being swallowed now, how
 > will we know when the test fails?

The "peer" thread saves off any Exceptions into {server,client}Exception 
volatile variable, which is then examined by the main thread at the end, 
and the stacktrace would be sent to System.out in the case of both the 
client/server throwing an exception.  Stuart pointed where exceptions 
were truly being swallowed when the threads are being created, and I've 
updated the webrev to address that.

> Also, I don't see where the change is invoking the newer framework? Am I
> looking
> at the right webrev?

Sorry, I used the word "framework" when I should have used "template." 
JSSE has a test template that I wrote back in the unbundled 1.0.3 days 
(2004) because we needed to do client/server-side testing, and we were 
always spending too much time getting the details worked out.  So I made 
a general template that most of the tests now use.  Most of the time 
only the top half of the test needs modification, but there are 
occasions where the initialization needs tweaking.

It could be made into a framework/library.  I've filed:

     JDK-8019776: Make the JSSE Test Templates into a library

There was no initCause/Suppressed back in those days, but those are good 
additions to add now.  We got the same debug info by printing the stack 
trace of any secondary exceptions.

Stuart wrote:

> The open URL to view this bug is:
>
>    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333

Whoops, my apologies.

> 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.

Good point, I'll capture that and add it as either the root cause, the 
init cause, or a suppressed exception (depending on what others there 
are to report), both here and in SSLSocketTemplate and friends.

> 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.

I believe we talked about that in earlier versions of the template.  If 
there's an Error, that's a more serious problem and nothing should be 
trusted coming out.  I would think the jtreg framework will output Errors.

> 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.

Sounds good.  I think I'd go with the initCause for peerException, and 
add a suppressed exception if there is an additional exception (unlikely).

New webrev under:

     http://cr.openjdk.java.net/~wetmore/8019341/webrev.01/

Brad