roded commented on a change in pull request #64:
URL: https://github.com/apache/jclouds/pull/64#discussion_r412901632
##########
File path: core/src/main/java/org/jclouds/http/config/SSLModule.java
##########
@@ -43,8 +44,8 @@
@Override
protected void configure() {
bind(HostnameVerifier.class).annotatedWith(Names.named("untrusted")).to(LogToMapHostnameVerifier.class);
- bind(new TypeLiteral<Supplier<SSLContext>>() {
- }).annotatedWith(Names.named("untrusted")).to(new
TypeLiteral<UntrustedSSLContextSupplier>() {
+ bind(new TypeLiteral<Supplier<SSLSocketFactory>>() {
+ }).annotatedWith(Names.named("untrusted")).to(new
TypeLiteral<UntrustedSSLSocketFactorySupplier>() {
Review comment:
I understand your concern. I could have
JavaUrlHttpCommandExecutorService accept both a nullable Supplier<SSLContext>
and a Supplier<SSLSocketFactory> for the untrusted use case as a fallback -
this will be in line with the existing behavior and shouldn't break existing
users providing SSLContext. In this case though, I suspect that only the
untrusted use case will be using the socket cache.
I'm not sure if the untrusted SSLSocketFactory supplier should build upon
another injected SSLContext supplier since these are currently mutually
exclusive use cases in JavaUrlHttpCommandExecutorService (and also I don't
think SSLContext can be init-ed twice).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
