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:42 GMT
Plus, if you are using google storage, it will automatically use SPDY :P

On Fri, Oct 3, 2014 at 12:05 PM, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> 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