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

[Michael McMahon]

On 28/06/13 02:38, Stuart Marks wrote:
> 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.
>

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

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

Michael

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