Re: [JDK-9] RFR: 8048618 Tests for PKCS12 write operations

Hi Max, Thanks for review, please check the update: http://cr.openjdk.java.net/~zailiu/8048618/webrev01/test/java/security/KeyStore/PKCS12/WriteP12Test.java.html Thanks again. Kevin 在 2015/3/18 14:23, Wang Weijun 写道: 33 * WriteP12CertChainBad: same as WriteP12CertChain but chains order

Re: [kitten] On stream-based GSSContext methods in RFC 5653

So what's your suggestion on their future? A: Remove them and say "they are removed" in a "Changed since" section. B: Move them to an appendix and say "they will not be developed anymore and please do not use them". C: Keep them in the old section and say "they will not be developed anymore

Re: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names

Yes, it will be extensive, but since we already make all keys OID, we should always call those set/get() with OIDs for performance. In case we might miss some, inside the implementation of get/set(), we can still accept names. Also, it seems there is no need for a nameCache everywhere, you can p

Re: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names

Hi Max, On 03/18/2015 04:09 PM, Wang Weijun wrote: Hi Jason I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? It might be, but it'd call for more extensive changes.

Re: [9] RFR: 7145757: CertificateExtensions uses non-consistent key names

Hi Jason I was thinking about changing all set/get calls to using OID so inside CertificateExtensions and CRLExtensions you won't need to care about name conversions. Is that possible? Also I see you adding some IOException throwing and catching. Is there any case you actually see them? I woul

[9] RFR: 8074531: Remove javax.security.cert.X509Certificate usage in internal networking packages

Please review this change, which removes methods in internal net packages that use the deprecated javax.security.cert.X509Certificate type. webrev: http://cr.openjdk.java.net/~juh/8074531/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8074531 Thanks, Jason

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

> On Mar 18, 2015, at 19:31, Artem Smotrakov wrote: > > The tests can be updated to start a new process with ProcessTools, or use a > script. Choose anyone you like. Maybe you can a few experiments to see what is the difference between a script test and a Java test that launches processes.

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

Yes, it looks like the classes are loaded from test.classes, here is a piece of jtr file CLASSPATH=/home/artem/tools/jtreg/4.1/lib/javatest.jar:/home/artem/tools/jtreg/4.1/lib/jtreg.jar:/home/artem/projects/security_test_colocation/jaas_subject_doas/results/reg/JTwork/classes/javax/security/auth

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

Honestly, writing a shell script test would be much cleaner, although it does not have the same performance as a Java test. Copying Jon, there should be cases where a script should be preferred. --Max > On Mar 18, 2015, at 17:39, Wang Weijun wrote: > > It looks like the classes are loaded fro

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

It looks like the classes are loaded from test.classes since there is nowhere setting classpath to those jars. Maybe you cannot rely on "@run main". --Max > On Mar 18, 2015, at 17:21, Artem Smotrakov wrote: > > Hi Max, > > Thank you for the review, it really helped to simplify the tests. I co

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

Hi Max, Thank you for the review, it really helped to simplify the tests. I combined your suggestions, please take a look: http://cr.openjdk.java.net/~asmotrak/8048147/webrev.01/ Artem On 03/17/2015 12:39 PM, Wang Weijun wrote: Hi Artem The tests are good but I am thinking if we can simpli