I've updated the PR to use multi bindings to provide the connection specs. Regarding the `Supplier<SSLContext>` optional injection, my main concern about providing a callback and removing the supplier is that the supplier approach is used in the other drivers. I agree that it would be more flexible to provide a specific callback for each driver, and even delete the "untrusted" configuration and delegate that configuration to callers, but that has the downside of having N different ways to configure the SSL connections, one for each driver.
In the end, SSL configuration is common to all HTTP drivers, and that config happens in the SSLContext in all them, so it makes sense to me to have a way of just providing a custom SSLContext, and the current `Supplier<SSLContext>` seems convenient to me. That should not be incompatible with creating post-configuration callbacks for each driver to let users have specific configurations, but having this common way of configuring SSL seems convenient to me. Is the real problem you see the optional injection, or the fact that the injection provides a gate just to configure a concrete thing in the HTTP driver? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/619#issuecomment-65001268
