Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 2/16/2016 22:54, Alan Bateman wrote: On 16/02/2016 14:44, Weijun Wang wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8130302/webrev.00/ I didn't abandon -providerClass and go all the way to -provideName because -providerClass has a sub-option -providerArg t

Re: Code Review Request, 8148500: [Spec] Enabled SSL Protocols may not be used

Looks good. --Sean On 02/15/2016 09:14 PM, Xuelei Fan wrote: It's nice. Here is the updated webrev: http://cr.openjdk.java.net/~xuelei/8148500/webrev/ Thanks, Xuelei On 2/16/2016 12:05 AM, Sean Mullan wrote: On lines 282-5 of SSLSocket, I think you should use similar language to be co

Re: Code Review Request 8139565 Restrict certificates with DSA keys less than 1024 bits

Looks good. --Sean On 02/16/2016 12:16 AM, Xuelei Fan wrote: Added a new regression test: http://cr.openjdk.java.net/~xuelei/8139565/webrev.01/ Thanks, Xuelei On 2/15/2016 8:23 AM, Xuelei Fan wrote: Hi, Please review this security crypto constraints update: http://cr.openjdk.java.

Re: RFR 8147772: Some KerberosTicket methods throw NPE after being destroyed

Looks good. --Sean On 02/14/2016 09:43 PM, Wang Weijun wrote: Webrev updated at http://cr.openjdk.java.net/~weijun/8147772/webrev.01/ with javadoc changes. Please review again. Thanks Max On Jan 20, 2016, at 10:22 PM, Wang Weijun wrote: On Jan 20, 2016, at 10:18 PM, Sean Mullan wro

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

On 16/02/2016 14:44, Weijun Wang wrote: Please review the code change at http://cr.openjdk.java.net/~weijun/8130302/webrev.00/ I didn't abandon -providerClass and go all the way to -provideName because -providerClass has a sub-option -providerArg that can be used to further configure the

RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

Please review the code change at http://cr.openjdk.java.net/~weijun/8130302/webrev.00/ I didn't abandon -providerClass and go all the way to -provideName because -providerClass has a sub-option -providerArg that can be used to further configure the provider. Also I think we still need to su

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

On 16/02/2016 11:05, Tim Du wrote: Hi Alan： I tried @compile/module to fix this issue before, but it does not work ,Use CertStatusReqExtensionTests.java as example, the process as below: 1. Create java.base/sun/security/ssl folder in test/sun/security/ssl/StatusStapling. 2. Move the dependen

Re: [9] RFR 8134487：updated sun/security/ssl/StatusStapling/* to work with modules

Hi Alan： I tried @compile/module to fix this issue before, but it does not work ,Use CertStatusReqExtensionTests.java as example, the process as below: 1. Create java.base/sun/security/ssl folder in test/sun/security/ssl/StatusStapling. 2. Move the dependency class like TestCase.java TestUtil

Re: jmx-dev [ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

Hi Jaroslav, I have no objection to this change. Could you add a comment somewhere to explain how you generated the truststore and keystore - in case we need to tweak that again in the future? best regards, -- daniel On 16/02/16 10:41, Jaroslav Bachorik wrote: On 11.2.2016 11:39, Jaroslav Ba

[ping] Re: RFR 8145919: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest failed with Connection failed for no credentials (Round 2)

On 11.2.2016 11:39, Jaroslav Bachorik wrote: Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145919 Webrev: http://cr.openjdk.java.net/~jbachorik/8145919/webrev.02 The previous attempt to fix this problem was focused on the fact that the test tend to f