This sounds like an http transport concern, Yury. Perhaps you can try a different driver, such as our okhttp one? Not saying this will automatically solve, but I am pretty sure the answer will be in the http driver. We may have a singleton somewhere in the default driver (which we could look into).
Let us know! -A On Oct 2, 2014 3:12 PM, "Yury Kats" <[email protected]> wrote: > I'm using jclouds 1.8 to communicate with Openstack Keystone server. > The server is using a self-signed cert. My client detects SSL connection > failure and allows the user to install the cert, which I add to JVM's trust > store. > > At this point I expect jclouds connections to succeed, but they continue > to fail. Until I shutdown the client and restart. > If the JVM trust store is loaded with the cert before jclouds makes its > first connection, all is good. > But if I change (add/remove) certs after the 1st connection is made, then > the change in JVM's trust store does not take effect on jclouds. > (For reference, I'm using AWS SDK in the same client, and there the change > takes effect immediately). > > Does jclouds cache connections or contexts? Is there a way to make it > "fully reconnect" (for a lack of a better term)? > > My code to talk to Keystone is like this: > KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new > KeystoneApiMetadata()) > .endpoint(url) > .credentials(tenant + ":" + user, key) > .buildApi(KeystoneApi.class); > > keystoneAPI.getServiceApi().listTenants(); > > PS: I am aware of Constants.PROPERTY_TRUST_ALL_CERTS, but that's not what > I want. > > Thanks, > Yury >
