Hi guys,
> 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.
Yes, please go ahead to merge those changes.
> I'll give a look to #508, not sure if I have sufficient knowledge
> for it.
>
>
> 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).
I like this idea, if you can come with some code - will appreciate
that!!!
Thank you.
WBR,
Alexey.
>
>
>
> 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
>
>