Hi Bruno,
Issue describing changes in SSLConfig:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=494
Basically aim was to provide defaults and remove need for providing keystore
and truststore if only key store was needed.
Changes made to SSLConfig kept it backward compatible on interface level and
relaxed restrictions put on users but allowing to configure kestore without
configuring truststore.
SSLConfigConfiguration is renamed SSLConfig, and yes I meant to merge
changes to that class.
I'll give a look to #508, not sure if I have sufficient knowledge for it.
And for use of libraries I don't know, but am trying to keep it simple by
not introducing any ;)
As for contributions they are more than welcome :)
Regards,
Huber
On Fri, Apr 3, 2009 at 2:13 AM, Bruno Harbulot <
Bruno.Harbulot_at_manchester.ac.uk> wrote:
> Hello,
>
> Hubert Iwaniuk wrote:
>
>> Hi Alexey,
>>
>> I've just finished SSLConfig refactoring.
>> Should it be merged to 2dot0?
>>
>
> Sorry, I haven't been following this for long. I'm not sure what the reason
> of the refactoring was, and I've certainly missed part of the story.
>
> I'd just like to point out issue #508 <
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=508> which I raised a
> few days ago, about the duplication of roles between SSLConfig and
> SSLImplementation (which creates conflicts of precedence of configuration or
> where SSLImplementation is sometimes not even used at all).
> There seems to be SSLContextConfiguration already in 2dot0. What would be
> the purpose of adding SSLConfig in this branch?
>
> At the moment (rev 2838), it looks like SSLConfig is an SSLContext factory
> augmented with settings for want/need client authentication (useful indeed).
> SSLContextConfiguration seems very similar. Did you mean merging SSLConfig
> in trunk into what's called SSLContextConfiguration in 2dot0? (I guess this
> would make sense.)
>
>
> In addition, as I was saying in issue #510 <
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=510>, not all
> keystores are file-based (or use an inputstream).
> This is why I wrote the KeyStoreLoader of jSSLutils [1] as it is. It's
> probably not perfect, but it seems to work fine and to have sensible default
> values (comments welcome, btw).
> I'd have written the SSLConfig/SSLContextConfiguration as a "merger" of
> jSSLutils's DefaultSSLContextFactory [2] and X509SSLContextFactory [3]
> (without the TrustManager wrappers) and preferably with the "PKIX" algorithm
> for the trust managers, which is now the default in the Sun JVM. (I'm not
> sure what the Grizzly policies are regarding use of other code/libraries or
> contributions, btw.)
> More importantly, it would be good to make
> SSLConfig/SSLContextConfiguration implement a simpler interface so that
> users can plug their own implementation (a bit like the intent of
> SSLImplementation).
>
>
> Best wishes,
>
> Bruno.
>
>
>
> I'm referring to revision 77 of jSSLutils - 0.6-SNAPSHOT, which simplifies
> a few things compared with earlier version (I hope).
> [1]
> http://code.google.com/p/jsslutils/source/browse/trunk/jsslutils/src/main/java/org/jsslutils/keystores/KeyStoreLoader.java
> [2]
>
> http://code.google.com/p/jsslutils/source/browse/trunk/jsslutils/src/main/java/org/jsslutils/sslcontext/DefaultSSLContextFactory.java
> [3]
> http://code.google.com/p/jsslutils/source/browse/trunk/jsslutils/src/main/java/org/jsslutils/sslcontext/X509SSLContextFactory.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>