Mailing-List: contact user-help@jclouds.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@jclouds.apache.org
Received-SPF: pass (athena.apache.org: domain of adrian.f.cole@gmail.com
 designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <542EE4A5.4020603@yahoo.com>
References: <542DCDB7.9020304@yahoo.com>
	<CAHzwyDutvnfAb1cyhzfT7+nacOGevKSqn9vcoaykxJFFx4+75w@mail.gmail.com>
	<20141003082651.pueu3kief4scs4c4@webmail.qrmedia.com>
	<542EA1C9.4030502@yahoo.com>
	<20141003155645.ti3n0vlh5w08480c@webmail.qrmedia.com>
	<542ECB7D.6080009@yahoo.com>
	<CAHzwyDuuXeYCHPR1jiATXs5hw_KC=Mj4xLoibKWG+R_46yCZ8Q@mail.gmail.com>
	<542ED753.9040607@yahoo.com>
	<CAHzwyDv85s+bkCXep9nLPA+xL1mq1X7U0Y_jB2vhTDNn-srwXQ@mail.gmail.com>
	<542EE4A5.4020603@yahoo.com>
Date: Fri, 3 Oct 2014 12:05:11 -0700
Message-ID: 
 <CAHzwyDuqiaErHx0m6ZJ+CwYX9uNze8iioX+Dw5jYZ9dg02RacQ@mail.gmail.com>
Subject: Re: Self-signed certs
From: Adrian Cole <adrian.f.cole@gmail.com>
To: user@jclouds.apache.org
Content-Type: text/plain; charset=UTF-8

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
>>>>     >
>>>>
>>>
>>
>