jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject Re: Self-signed certs
Date Fri, 03 Oct 2014 19:05:11 GMT
Glad to hear it worked.

Disclaimer: I am a committer on okhttp.

OkHttp acknowledges that the JRE HttpUrlConnection class has not been
awesome, particularly if someone wants a similar experience across jre
versions and android. It has a lot of tests around network and TLS
concerns. I'd recommend using it, eventhough we could probably
configure it better in our driver.

http://square.github.io/okhttp/

-A

On Fri, Oct 3, 2014 at 11:02 AM, Yury Kats <yurykats@yahoo.com> wrote:
> Awesome, this worked! Thank you!
>
> And please ignore my previous comment about non-default drivers not being used.
> It was a user error -- I put into wrong code path, so it wasn't exercised.
>
> But providing my own SSL context is even better.
>
> So there is definitely something's wrong with the default http driver as far as ssl/connection
handling. Something's cached forever.
>
> Aside from this SSL issue, are there any other reasons for me to look at okhttp or apachehc
drivers?
>
> Thanks again!
>
> On 10/3/2014 1:22 PM, Adrian Cole wrote:
>> That sounds very strange indeed. I don't have an answer for how to
>> verify which driver is in use, except maybe put a breakpoint.
>>
>> PS I had a quick look at the code [1]. It seems we are wired to
>> optionally accept Supplier<SSLContext> if the user binds one. This
>> would also be used with OkHttp according to the current impl.
>>
>> In other words, you can try this to manage your own ssl context on a
>> per-request basis. If you have luck doing this, then maybe we can
>> arrange a test case that replicates the scenario you discuss.
>>
>> .modules(ImmutableSet.of(new AbstractModule(){
>>   @Override public void configure() {
>>     bind(new TypeLiteral<Supplier<SSLContext>>(){}).toInstance(new
>> Supplier<SSLContext>() {
>>       @Override public SSLContext get() {
>>         return whatYouManage; // note this is called per-request so
>> can be expensive.
>>       }
>>     }
>>   }
>> }))
>>
>> [1] https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L207
>>
>> On Fri, Oct 3, 2014 at 10:05 AM, Yury Kats <yurykats@yahoo.com> wrote:
>>> Tried both, no change in behavior.
>>>
>>> However, what's confusing, is that if I add just the jclouds-okhttp jar, without
pulling its dependencies (no okhttp and okio),
>>> I can still instantiate the KeystoneApi and connect
>>>
>>>  KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new KeystoneApiMetadata())
>>>                 .endpoint(url)
>>>                 .credentials(tenant + ":" + user, key)
>>>                 .modules(ImmutableSet.of(new OkHttpCommandExecutorServiceModule()))
>>>                 .buildApi(KeystoneApi.class);
>>>
>>> Which makes me think the driver is not being utilized, regardless of the .modules()
modifier.
>>>
>>> How can I confirm what driver is actually being used to make the connection?
>>>
>>>
>>> On 10/3/2014 12:44 PM, Adrian Cole wrote:
>>>> Nope that's it. Same process for the okhttp one (if you wish to try it)
>>>>
>>>> -A
>>>>
>>>> On Oct 3, 2014 9:15 AM, "Yury Kats" <yurykats@yahoo.com <mailto:yurykats@yahoo.com>>
wrote:
>>>>
>>>>     Thanks, got them.
>>>>
>>>>     So to use those drivers, all I need to do  is add
>>>>
>>>>             .modules(ImmutableSet.of(new ApacheHCHttpCommandExecutorServiceModule()))
>>>>
>>>>     into
>>>>
>>>>             KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new KeystoneApiMetadata())
>>>>                     .endpoint(url)
>>>>                     .credentials(tenant + ":" + user, key)
>>>>                     .buildApi(KeystoneApi.class);
>>>>
>>>>     Or is there more to it?
>>>>
>>>>     On 10/3/2014 9:56 AM, Andrew Phillips wrote:
>>>>     > Hi Yury
>>>>     >
>>>>     >> I don't seem to find those in any of the jclouds 1.8.0 jars.
>>>>     >> Where do I get them from?
>>>>     >
>>>>     > They're additional dependencies with GA
>>>>     > org.apache.jclouds.driver:jclouds-okhttp and
>>>>     > org.apache.jclouds.driver:jclouds-apachehc [1] respectively. You
>>>>     > should be able to add them to your project as just an additional
Maven
>>>>     > dependency (if you're using Maven) - they'll take care of wiring
them
>>>>     > up themselves.
>>>>     >
>>>>     > If you have any questions or it doesn't seem to work, please give
us
>>>>     > some more details about your project setup (e.g. are you using Maven?).
>>>>     >
>>>>     > Regards
>>>>     >
>>>>     > ap
>>>>     >
>>>>     > [1] http://search.maven.org/#search%7Cga%7C1%7Cjclouds%20driver
>>>>     >
>>>>
>>>
>>
>

Mime
View raw message