Hi Bruno,
thank you for your observation.
I'm currently working on Grizzly 2.0, where I split SSL configuration
into: SSLContextConfigurator [1] and SSLEngineConfigurator [2].
And planning to replace SSLImplementation and SSLSupport in Grizzly
http module with [1] and [2] entities.
But as I told, I'm just planning to do that for Grizzly 2.0, which is
currently in impl. state, and will be very interesting to hear your
feedback and appreciate any help you can provide.
Thanks.
WBR,
Alexey.
[1]
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/main/java/org/glassfish/grizzly/ssl/SSLContextConfigurator.java?view=markup
[2]
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/main/java/org/glassfish/grizzly/ssl/SSLEngineConfigurator.java?view=markup
On Mar 31, 2009, at 2:56 , Bruno Harbulot wrote:
> Hello,
>
> Jeanfrancois Arcand wrote:
>
>>>> I'm was recently looking at GWS and its HTTPS support.
>>>> I found out that user can start GWS configured to serve HTTPS
>>>> without SSLConfig.
>>>> This renders service unusable.
>>> We can try to use some "default" SSLConfig, which reads SSL
>>> configuration from System properties.
>>>
>>>> What do you think of deprecating constructor with boolean secure
>>>> parameter and creating one that would require SSLConfig?
>>> IMHO it could be even more clear, if we can split GrizzlyWebServer
>>> implementation into two: Secure and non-Secure.
>
>
> Perhaps this thread on glassfish-dev might be of interest [1]. (I've
> just posted something about it a few minutes ago, but my e-mail
> doesn't seem to have arrived yet).
>
>
>> Hum :-) I would think it is much simpler to have a single entry
>> point. A default SSLConfig is probably what we want (JDK 7 will add
>> that features).
>
> I'm surprised. This looks similar to an SSLContext factory, which I
> tried to suggest a few months ago on the security-dev_at_openjdk list,
> and the conclusion was that this didn't really belong in the JRE [2].
>
>
> Regarding SSLConfig, since I've already done some similar work for
> Tomcat [3], Jetty [4] and Restlet (including the Grizzly connector
> of Restlet, but that was easy enough because there was a
> setSSLContext already), I wouldn't mind helping here. These issues
> in these other projects were about SSLContexts that are not file-
> based (nor inputstream-based), such as PKCS#11 tokens and Apple's
> KeychainStore. In fact, this work was one of reasons for me to
> package these utilities (especially SSLContextFactory) as jSSLutils
> [5].
>
>
> Best wishes,
>
> Bruno.
>
>
>
> [1] https://glassfish.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=1661989
> [2] http://mail.openjdk.java.net/pipermail/security-dev/2009-January/000509.html
> [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=43094
> [4] http://jira.codehaus.org/browse/JETTY-456
> [5] http://code.google.com/p/jsslutils/source/browse/trunk/jsslutils/src/main/java/org/jsslutils/sslcontext/SSLContextFactory.java
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>