webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.00/
No new regression test, the current test,
test/sun/security/tools/keytool/printssl.sh, has already been able to
test the update.
Thanks,
Xuelei
Hi Xuelei
Why move the local variables to static fields?
The engineGetCertificates method is only synchronized on this but not the whole
class, so there is a chance that the method is called by multiple threads at
the same time. This means if you only use one static GetChainTrustManager
field,
Hi Xuelei
Please take a review:
http://cr.openjdk.java.net/~weijun/7115744/webrev.00/
Most are krb5 tests, one for SSL.
Thanks
Max
Begin forwarded message:
> *Change Request ID*: 7115744
> *Synopsis*: Do not call File::deleteOnExit in security tests
>
>
> === *Description* =
On 11/26/2011 9:59 PM, Weijun Wang wrote:
> Hi Xuelei
>
> Why move the local variables to static fields?
>
In order to improve the performance. SSLContext.init() is expensive.
> The engineGetCertificates method is only synchronized on this but not the
> whole class, so there is a chance that th
Looks fine to me.
As you did not update the copyright years, I think you will only push
the changes to JDK 8. It's OK to me in case you don't want putback to
JDK 7. Otherwise, I would suggest you update the copyright years.
Xuelei
On 11/26/2011 10:38 PM, Weijun Wang wrote:
> Hi Xuelei
>
> Pleas
I was wondering why we synchronized the getInstance() and
engineGetCertificates(). It seems that we only need to synchronize the
serverChain variable.
I will update the synchronization if no objection.
Thanks,
Xuelei
On 11/26/2011 10:42 PM, Xuelei Fan wrote:
> On 11/26/2011 9:59 PM, Weijun Wang
On Nov 26, 2011, at 10:58 PM, Xuelei Fan wrote:
> I was wondering why we synchronized the getInstance() and
> engineGetCertificates(). It seems that we only need to synchronize the
> serverChain variable.
>
> I will update the synchronization if no objection.
>
> Thanks,
> Xuelei
>
> On 11
new webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.01/
You're right on the synchronization issue. In the new webrev, I also
remove the "synchronized" keyword on method. Instead, a synchronization
on the static attribute is used.
Thanks,
Xuelei
On 11/26/2011 11:16 PM, Weijun Wang wrote
There is one thing I'm not sure about:
In which case(s), the GeneralSecurityException will be thrown? Is it possible
that the exception is thrown sometimes but not always? Also, the old code has
the exception as a clause of the CertStoreException. Can you also include it?
Max
On Nov 26, 2011
Sent from my iPad
On Nov 27, 2011, at 12:23 AM, Weijun Wang wrote:
> There is one thing I'm not sure about:
>
> In which case(s), the GeneralSecurityException will be thrown?
SSLContext initialization.
> Is it possible that the exception is thrown sometimes but not always? Also,
> the old c
>> Is it possible that the exception is thrown sometimes but not always?
If it always fails, there is no problem failing once at the beginning.
Otherwise, if there is a chance it goes fine again after calling some
codes, maybe it's better to try call it each time?
Max
On 11/27/2011 09:05 AM,
Sent from my iPad
On Nov 27, 2011, at 9:49 AM, Weijun Wang wrote:
> >> Is it possible that the exception is thrown sometimes but not always?
>
> If it always fails, there is no problem failing once at the beginning.
> Otherwise, if there is a chance it goes fine again after calling some code
12 matches
Mail list logo
