> On Jun 12, 2016, at 11:33 AM, Alan Bateman wrote:
>
>
>
> On 12/06/2016 13:44, Wang Weijun wrote:
>> I was about to send out a new webrev (CCC just approved) but noticed a
>> behavior change.
>>
>> Although "-addprovider SUN" is useless it still worked when I posted
>> webrev.03, but now
On 12/06/2016 13:44, Wang Weijun wrote:
I was about to send out a new webrev (CCC just approved) but noticed a behavior
change.
Although "-addprovider SUN" is useless it still worked when I posted webrev.03, but now
it failed, because ServiceLoader.load(Provider.class) does not contain "SUN"
I was about to send out a new webrev (CCC just approved) but noticed a behavior
change.
Although "-addprovider SUN" is useless it still worked when I posted webrev.03,
but now it failed, because ServiceLoader.load(Provider.class) does not contain
"SUN" anymore. Maybe it is inside java.base and
On 23/03/2016 08:12, Wang Weijun wrote:
Now that jake/m3 is in jdk9/dev I assume I will just include the jake-related
codes and directly push a single changeset to jdk9/dev. Right?
Yes, changes like this this can be pushed via jdk9/dev. In the
mean-time, we will continue to work in jigsaw/ja
>
>> The SunPKCS11 compatibility line will be add in a sub-patch for jake.
>>
>
> You can send me the jake’s delta patch once you push the change to jdk9/dev.
I've been busy recently on DRBG and will be back working on this one.
Now that jake/m3 is in jdk9/dev I assume I will just include the
> On Feb 26, 2016, at 1:03 AM, Sean Mullan wrote:
>
> On 02/18/2016 03:10 AM, Weijun Wang wrote:
>> There is another compatibility issue which is more important:
>>
>> Today, we tell users to load their own PKCS11 provider with
>>
>> -providerClass sun.security.pkcs11.SunPKCS11 -providerArg
On 02/18/2016 03:10 AM, Weijun Wang wrote:
There is another compatibility issue which is more important:
Today, we tell users to load their own PKCS11 provider with
-providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg
and seems the new options should be
-provider SunPKCS11
> On Feb 22, 2016, at 7:28 PM, Wang Weijun wrote:
>
> Webrev updated at http://cr.openjdk.java.net/~weijun/8130302/webrev.03/.
>
> -provider and loadProviderByName() are useless for jdk9/dev, and
> loadProviderByClass() only uses reflection.
>
I reviewed the provider loading part and looks g
Webrev updated at http://cr.openjdk.java.net/~weijun/8130302/webrev.03/.
-provider and loadProviderByName() are useless for jdk9/dev, and
loadProviderByClass() only uses reflection.
The SunPKCS11 compatibility line will be add in a sub-patch for jake.
--Max
> On Feb 23, 2016, at 10:25 AM, Wan
>>
>> You mean not supporting all pre-loaded providers in modules, but only one or
>> two popular ones?
>>
>
> I meant not support -providerClass for arbitrary providers loaded via service
> loader. The only exception is SunPKCS11. In other words, -providerClass can
> only be used to load l
> On Feb 22, 2016, at 5:55 PM, Wang Weijun wrote:
>
303 // A provider in module can also be use class name
304 if (p.getClass().getName().equals(provClass)) {
ProviderConfig::getProvider doesn’t compare the classname. I thought we
agree to
>>>
>>> 303 // A provider in module can also be use class name
>>> 304 if (p.getClass().getName().equals(provClass)) {
>>>
>>> ProviderConfig::getProvider doesn’t compare the classname. I thought we
>>> agree to discourage the use of -providerClass to load a provider and
> On Feb 21, 2016, at 1:45 AM, Wang Weijun wrote:
>
>
>> On Feb 20, 2016, at 4:01 AM, Mandy Chung wrote:
>>
>>
>>> On Feb 19, 2016, at 2:47 AM, Wang Weijun wrote:
>>>
>>> Updated at the same URL
>>>
>>> http://cr.openjdk.java.net/~weijun/8130302/webrev.01
>>>
>>> The help looks like this
[I thought I sent out this but cannot find it in my inbox. Send again]
New webrev at
http://cr.openjdk.java.net/~weijun/8130302/webrev.02/
This is for jdk9/dev.
I'll send out a sub-patch for jake, which includes an extra addRead call and
more test changes.
security-dev, I haven't heard any
> On Feb 20, 2016, at 4:01 AM, Mandy Chung wrote:
>
>
>> On Feb 19, 2016, at 2:47 AM, Wang Weijun wrote:
>>
>> Updated at the same URL
>>
>> http://cr.openjdk.java.net/~weijun/8130302/webrev.01
>>
>> The help looks like this now:
>>
>> -provider add security provider by name (e.g
> On Feb 19, 2016, at 2:47 AM, Wang Weijun wrote:
>
> Updated at the same URL
>
> http://cr.openjdk.java.net/~weijun/8130302/webrev.01
>
> The help looks like this now:
>
> -provider add security provider by name (e.g. SunPKCS11)
> [-providerArg ] configure argument for -pro
On 19/02/2016 11:17, Wang Weijun wrote:
:
When and which repo should this change go into? Certainly this is all about
jake but there are a lot of other changes, esp, the option list.
Good question. Ideally jdk9/dev as we are trying to minimize the changes
in the jake forest. If you do that
> On Feb 19, 2016, at 6:58 PM, Alan Bateman wrote:
>
> One other thing is whether we should add a section to JEP 261 on these tool
> updates. I had originally assumed that the updates to these tools would
> follow the module system into JDK 9 but you've turned up early :-)
When and which repo
On 19/02/2016 10:47, Wang Weijun wrote:
Updated at the same URL
http://cr.openjdk.java.net/~weijun/8130302/webrev.01
The help looks like this now:
-provider add security provider by name (e.g. SunPKCS11)
[-providerArg ] configure argument for -provider
-providerclas
Updated at the same URL
http://cr.openjdk.java.net/~weijun/8130302/webrev.01
The help looks like this now:
-provider add security provider by name (e.g. SunPKCS11)
[-providerArg ] configure argument for -provider
-providerclass add security provider by fully-qualified c
> On Feb 19, 2016, at 5:36 PM, Alan Bateman wrote:
>
>
> On 19/02/2016 09:07, Wang Weijun wrote:
>> :
>> I don't want the line to be too long. Is the preferred terminal width still
>> 80 now? I noticed the java help output still fits with 80 chars but javac is
>> already not.
> It could fit o
On 19/02/2016 09:07, Wang Weijun wrote:
:
I don't want the line to be too long. Is the preferred terminal width still 80
now? I noticed the java help output still fits with 80 chars but javac is
already not.
It could fit on a second line, the java launcher usage output does this.
I see jarsig
> On Feb 19, 2016, at 4:42 PM, Alan Bateman wrote:
>
> On 19/02/2016 08:22, Wang Weijun wrote:
>> A new webrev at
>>
>>http://cr.openjdk.java.net/~weijun/8130302/webrev.01/
>>
>> The options for keytool have
>>
>> -provider [-providerArg ]add a provider by name
>> -providerclas
On 19/02/2016 08:22, Wang Weijun wrote:
A new webrev at
http://cr.openjdk.java.net/~weijun/8130302/webrev.01/
The options for keytool have
-provider [-providerArg ]add a provider by name
-providerclass [-providerArg ] add a provider by classname
(omit some words because lin
A new webrev at
http://cr.openjdk.java.net/~weijun/8130302/webrev.01/
The options for keytool have
-provider [-providerArg ]add a provider by name
-providerclass [-providerArg ] add a provider by classname
(omit some words because line is too long)
for jarsigner
[-provider
> On Feb 18, 2016, at 1:52 AM, Alan Bateman wrote:
>
>
> On 18/02/2016 09:08, Weijun Wang wrote:
>> OK, but with -providerClass I'd like to support a class name even if it is
>> already defined in a module as a service and has its own name. This makes
>> sure old commands still work.
> I thin
On 18/02/2016 09:08, Weijun Wang wrote:
OK, but with -providerClass I'd like to support a class name even if
it is already defined in a module as a service and has its own name.
This makes sure old commands still work.
I think it should work fine but I assume we would want to discourage
this.
OK, but with -providerClass I'd like to support a class name even if it
is already defined in a module as a service and has its own name. This
makes sure old commands still work.
The existing -providerClass takes a class name and works as before. The
-provider takes the name of a security prov
On 18/02/2016 08:10, Weijun Wang wrote:
:
Today, we tell users to load their own PKCS11 provider with
-providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg
and seems the new options should be
-provider SunPKCS11 -providerArg some.cfg
Why not just support all these formats?
In keytool help, we will write
-providerAdd a security provider with its name
“Add a security provider by the provider’s name”
-providerArgOptional argument for -provider above
-providerClass Add a security provider with its class name
“Add a security provider b
> On Feb 17, 2016, at 8:04 PM, Wang Weijun wrote:
>
>>
>> On Feb 18, 2016, at 9:21 AM, Mandy Chung wrote:
>>
>>>
>>> On Feb 17, 2016, at 4:46 PM, Wang Weijun wrote:
>>>
>>>
On Feb 18, 2016, at 5:15 AM, Mandy Chung wrote:
Can I say -providerClass -providerArg is equivale
> On Feb 18, 2016, at 9:21 AM, Mandy Chung wrote:
>
>>
>> On Feb 17, 2016, at 4:46 PM, Wang Weijun wrote:
>>
>>
>>> On Feb 18, 2016, at 5:15 AM, Mandy Chung wrote:
>>>
>>> Can I say -providerClass -providerArg is equivalent to
>>> extending java.security to add “security.provider.N=NAME
> On Feb 17, 2016, at 4:46 PM, Wang Weijun wrote:
>
>
>> On Feb 18, 2016, at 5:15 AM, Mandy Chung wrote:
>>
>> Can I say -providerClass -providerArg is equivalent to
>> extending java.security to add “security.provider.N=NAME ARG”?
>
> Yes.
>
>>
>> I suggest to keep -providerClass and -
> On Feb 18, 2016, at 5:15 AM, Mandy Chung wrote:
>
> Can I say -providerClass -providerArg is equivalent to extending
> java.security to add “security.provider.N=NAME ARG”?
Yes.
>
> I suggest to keep -providerClass and -providerArg only for legacy security
> provider (i.e. not a service
> On Feb 16, 2016, at 5:20 PM, Weijun Wang wrote:
>
>
>
> 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
On 2/17/2016 18:33, Alan Bateman wrote:
On 17/02/2016 01:20, Weijun Wang wrote:
:
Technically they are independent.
With -providerClass/-providerArg, the provider is added into system
and getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it.
On the other hand, -providerName c
On 17/02/2016 01:20, Weijun Wang wrote:
:
Technically they are independent.
With -providerClass/-providerArg, the provider is added into system
and getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it.
On the other hand, -providerName can be used to specifically tell
KeyPairG
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
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
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
40 matches
Mail list logo