Mailing-List: contact user-help@jclouds.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@jclouds.apache.org
Received-SPF: pass (nike.apache.org: domain of yurykats@yahoo.com designates
 98.139.213.141 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=pZ4zVuDxTPog/4ZFeRyrgorHAfhTNvnB3Jwdkd6cSTvSWrxpPKK6d6dOe6SJx6ckk1tunTYcbXxmKWHV9FX9f0hBrLoZbQv/1WNc5IZfbwJFfoom82yy5TyZHC2DXd0ahajDLR+cqsuPWpq35noA/SjMan2nQS7RFPHnzG2MiD8rpddhlW3oT+LVUij3aDuU+So6c1c74969m1nRF0QOXMe0jO+qd2+cNEt/z96YGEBok6jj47ELX6teCeuXT9wMjjtfKwfUDHJk18K3lLsCowdV1VY/eHBliHYtQWxIXnx9F8BNgtCrWRF1LZNJJdVDonOQ0xXxJUzGk/jREGs61g==;
Message-ID: <542EE4A5.4020603@yahoo.com>
Date: Fri, 03 Oct 2014 14:02:13 -0400
From: Yury Kats <yurykats@yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.7.1
MIME-Version: 1.0
To: user@jclouds.apache.org
Subject: Re: Self-signed certs
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>
In-Reply-To: 
 <CAHzwyDv85s+bkCXep9nLPA+xL1mq1X7U0Y_jB2vhTDNn-srwXQ@mail.gmail.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

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