Oh, not the last one. Here is a new one that uses String instead of
CipherSuite.KeyExchange in the service interface. 1) below is thus resolved.
http://cr.openjdk.java.net/~weijun/8038089/webrev.07/
Thanks
Max
On 5/26/2015 11:32 AM, Weijun Wang wrote:
This is the latest webrev of this bug
sun/security/jca/ProviderConfig.java
287 /**
288 * Loads the provider with the specified class name.
289 *
290 * @param name the name of the provider class
291 * @return the Provider, or null if it cannot be found or
loaded
292 * @throw
Thanks, I will sort out the Makefile stuff with Mandy and other build
experts...
Valerie
On 5/26/2015 1:57 PM, Sean Mullan wrote:
This all looks fine to me (except for the Makefile stuff which I'll
leave to others).
--Sean
On 05/21/2015 12:21 AM, Valerie Peng wrote:
Sean,
Could you please
This all looks fine to me (except for the Makefile stuff which I'll
leave to others).
--Sean
On 05/21/2015 12:21 AM, Valerie Peng wrote:
Sean,
Could you please review this change? The changes are mostly the same as
the prototype in Jake, but I have to make some modification due to the
differe
Hello,
partial quote as I want to add to a point:
Am Tue, 26 May 2015 16:19:59 -0400
schrieb Michael Maass :
> 3. Common security reasons to use the sandbox: (a) using a third
> party library that isn't fully trusted (convenience often trumps
> security) and (b) frameworks loading third party pl
I've been working on addressing similar issues as part of my PhD thesis
and have noted many of the same challenges, although I've taken a
different approach. Some points I can add from a recent but currently
unpublished study of actual usage of the Java sandbox (I can send a
draft to individual
> I am not sure I follow this. Can you please sketch the steps/algorithm
> that will be done in your proposed solution ?
I'm assuming you are talking about 1a and not 1b.
Sure, most of the heavy lifting takes place in ServerHandshaker.
ServerHandshaker.java
=
In the SunJSSE
On 05/26/2015 09:45 AM, Weijun Wang wrote:
But here it's not a real singleton (not final), the refresh() method can
reassign an instance to it.
Oh. I missed that. Forget my suggestion then.
--Sean
--Max
On 5/26/2015 8:51 PM, Sean Mullan wrote:
I would use the Initialization-on-demand hold
But here it's not a real singleton (not final), the refresh() method can
reassign an instance to it.
--Max
On 5/26/2015 8:51 PM, Sean Mullan wrote:
I would use the Initialization-on-demand holder idiom [1] instead, ex:
private static class SingletonHolder {
private static final Config si
I would use the Initialization-on-demand holder idiom [1] instead, ex:
private static class SingletonHolder {
private static final Config singleton = new Config();
}
public static Config getInstance() throws KrbException {
return SingletonHolder.singleton;
}
This way you avoid synchroni
Hi,
On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore
wrote:
> Darn those Chicken/Eggs [1]!
>
> Yes, you are correct. The steps for the current server code:
>
> 1. The ClientHello is parsed, and the SNI matcher callback is called. It
> does not return which value was matched in the ServerHello,
11 matches
Mail list logo
