Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Hello Sean, An empty array is allowed: it means do not use ALPN. I’ve updated the exception messages to display the offending length in each case. --- ALPNExtension.java Tue Dec 1 15:22:02 2015 +++ ALPNExtension.java Tue Dec 1 14:56:12 2015 @@ -97,11 +97,13 @@ listLength =

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

I just would like to remind that session resumption is a very important use case to support for ALPN. Understood. The ALPN value is tied to a handshake, either already completed and active (getApplicationProtocol()) or still in progress (getHandshakeApplicationProtocol()). Each handshake

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

298: This test is not actually calling into checkResult on the server side. Ooops! You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult. You need to put in a similar checkResult() before doing the flip()s. So checks are required before

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

On 12/2/2015 9:05 AM, Wang Weijun wrote: > Socket is a Closeable, so you can > > try (Socket sock = ) { ... } > Yes. Better coding. Updated in the same webrev. > If you want more debug messages, why not e.printStackTrace()? Message is > enough? > I was wondering, the cached

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

On 12/2/2015 10:20 AM, Wang Weijun wrote: > >> On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: >> >> On 12/2/2015 9:05 AM, Wang Weijun wrote: >>> Socket is a Closeable, so you can >>> >>> try (Socket sock = ) { ... } >>> >> Yes. Better coding. Updated in the same

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

Everything looks fine now. Thanks Max > On Dec 2, 2015, at 10:48 AM, Xuelei Fan wrote: > > On 12/2/2015 10:20 AM, Wang Weijun wrote: >> >>> On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: >>> >>> On 12/2/2015 9:05 AM, Wang Weijun wrote:

Code Review Request 8143298 Test ReadTimeout.java fails intermittently

Hi, Please review the test fix for JDK-8143298: http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/ The root cause of the intermittent test failure is still unclear to me. I updated the test with more output messages, and clear the resources in finally blocks. Hope the update can expose

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

Socket is a Closeable, so you can try (Socket sock = ) { ... } If you want more debug messages, why not e.printStackTrace()? Message is enough? Thanks Max > On Dec 2, 2015, at 8:55 AM, Xuelei Fan wrote: > > Hi, > > Please review the test fix for JDK-8143298: >

Re: S4U2Self and OpenJDK 8

> On Dec 2, 2015, at 1:59 AM, Marc Boorshtein > wrote: > > Max, > > Closing the loop on this. It turns out that there was an extra step > needed to get the user in freeipa setup as a delegate (the > documentation was written for S4U2Proxy, not S4U2Self).

Re: Code Review Request 8143298 Test ReadTimeout.java fails intermittently

> On Dec 2, 2015, at 9:12 AM, Xuelei Fan wrote: > > On 12/2/2015 9:05 AM, Wang Weijun wrote: >> Socket is a Closeable, so you can >> >> try (Socket sock = ) { ... } >> > Yes. Better coding. Updated in the same webrev. Same sslSocket declared twice. Have you

Re: openjdk 8 & 2048 bit DSA xml signing

I opened a backport for this issue for a JDK 8 update release, see: https://bugs.openjdk.java.net/browse/JDK-8143905 The backport should be relatively straightforward, but I am not sure yet when or what release the fix will appear in. --Sean On 11/19/2015 04:53 AM, Basabendra Misra wrote:

Re: S4U2Self and OpenJDK 8

Max, Closing the loop on this. It turns out that there was an extra step needed to get the user in freeipa setup as a delegate (the documentation was written for S4U2Proxy, not S4U2Self). Once I set that flag delegation started working for BOTH Java 8 and Java 9. Thanks again. Marc Boorshtein

Code Review Request, 8144313, Test SessionTimeOutTests can be timeout

Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/ In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of "serverReady" variable was not synchronized when performing multiple operations, as may result that the variable cannot be

Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable

Hi, Please review the fix for JDK-8133070: http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/ In (Open)JDK 6, EC cipher suites get supported by Java. However, there is no default EC provider in JDK 6 at that time. In order to support third part's EC algorithm JCE provider dynamically,

Re: Code Review Request, 8144313, Test SessionTimeOutTests can be timeout

serverReady doesn't need to be volatile anymore. Looks good otherwise. --Sean On 12/01/2015 05:48 AM, Xuelei Fan wrote: Hi, Please review this test update: http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/ In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Hey Vinnie, question on SSLParameters.setApplicationProtocols(String[] protocols) method What happens if you pass an empty array into this method. Shouldn't it throw an IllegalArgumentException ? In ALPNExtension.java : +if (listLength < 2 || listLength + 2 != len) { +

Re: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256

On 11/25/2015 09:39 PM, Wang Weijun wrote: Updated at http://cr.openjdk.java.net/~weijun/8141457/webrev.01/. I was lazy last time. Looks good. --Sean --Max On Nov 24, 2015, at 8:15 PM, Sean Mullan wrote: Looks good - although you could replace the MD5