Hi Ignasi, I just read your mail after having done the Bug in JIRA (#1220) and the PR on github (#1046). I managed to "have something working" by adding a requestStaticInjection but I understand it is not the "standard method" for Jclouds. If I move to the binder class, do the injection will be "automatic" or something has to be declared ?
Thanks in advance, Regards, Etienne Carrière 2017-01-03 16:11 GMT+01:00 Ignasi Barrera <n...@apache.org>: > Hi Etienne, > > Apologies for the late reply. I've had a look at your patch and I like > proposed the solution. > > I think the problem in your code is that you are configuring the > injection in the Guice module itself. Guice modules are used to > configure "what and how" is injected, but they should not contain > injected variables or constructors, since one manually instantiates > them (when passing it to the context builder) instead of requesting an > instance to the Guice injector. > > Making it work would be simple: just move all the header constants and > variables to your Binder class and let injection happen there. It also > makes more sense, since that's the place where the headers are needed. > > Let us know if that works, and look forward to seeing a PR for this! :) > > > HTH! > > I. > > On 30 December 2016 at 17:59, Etienne Carriere > <etienne.carri...@gmail.com> wrote: > > Hi Andrea, > > > > Thank you for your answer. > > Concerning the 2 points : > > * my current patch is available here : > > https://github.com/Etienne-Carriere/jclouds/commit/ > fd9057573935b6f95e8cab6526790e0b79a5e843#diff- > 4f8d0e6c4a8bc4add7203bcbfe4bbf6eR71 > > * I take the example on the BaseAuthenticator class ( > > https://github.com/jclouds/jclouds/blob/4bbca9edf943852ce1ea5aa579fa05 > 54f770a3ea/apis/openstack-keystone/src/main/java/org/ > jclouds/openstack/keystone/v2_0/functions/internal/ > BaseAuthenticator.java#L45) > > for the injection of the property given through overrides method of the > > builder. > > > > Unfortunately it doesn't work . The value of the variable is null even > if I > > push the property. > > > > Regards, > > > > Etienne Carrière > > > > > > > > > > 2016-12-30 16:58 GMT+01:00 Andrea Turli <andrea.tu...@gmail.com>: > > > >> Hi Etienne, > >> > >> sorry for the late answer. > >> > >> Unfortunately I'm not really familiar with this details of swift but I > >> think what you are proposing makes sense to me. > >> > >> I'd suggest to fist send a working example, maybe updating > >> https://github.com/jclouds/jclouds-examples/tree/master/ > blobstore-basics > >> but not sure, and potentially re-start there the conversation around the > >> question #1 > >> > >> Re #2, can you elaborate a bit more when you say "we have issues to use > the > >> variables injected by the overrides method" what are you trying to > achieve? > >> > >> HTH, > >> Andrea > >> > >> On Wed, Dec 28, 2016 at 4:36 PM, Etienne Carriere < > >> etienne.carri...@gmail.com> wrote: > >> > >> > Hi, > >> > > >> > In our project, we currently need to interact with differents types of > >> > swift implementations : > >> > - Ceph with radosgw > >> > - NetApp appliance with swift endpoint > >> > > >> > Thoses implementions use "identity v1 protocol" which is an old but > >> simple > >> > API for the authentication and don't use identity v2 protocol ( > >> > http://developer.openstack.org/api-ref/identity/v2/index.html) which > is > >> > implemented by jclouds in openstack-keystone module . > >> > > >> > > >> > *State of jclouds* > >> > The openstack swift "official" client (in python) manage this v1 > >> protocol ( > >> > http://docs.openstack.org/developer/python-swiftclient/ > swiftclient.html) > >> > so > >> > even if we don't have a specification, we will use the code of the > >> official > >> > client for the implementation. > >> > > >> > In jclouds, there is currently a sort-of v1 identity protocol in the > >> > openstack-swift module: in > >> > apis/openstack-swift/src/main/java/org/jclouds/openstack/ > >> swift/v1/config/ > >> > SwiftAuthenticationModule.java, > >> > there is a tempAuthCredentials which is almost the identity v1 > protocol > >> > except that the name of the headers was not the same : > >> > = X-Storage-User vs X-Auth-User > >> > = X-Storage-Path vs X-Auth-Key > >> > > >> > *Proposal* > >> > In our project, we think about the following solution > >> > = Keep the current behaviour as default > >> > = Add 2 parameters to change the header name through variables in > the > >> > Properties put in the Builder like that : > >> > > >> > Properties overrides = new Properties(); > >> > overrides.setProperty("jclouds.keystone.credential-type", > >> > "tempAuthCredentials"); > >> > overrides.setProperty("jclouds.swift.tempAuth.headerUser", > >> > "X-Auth-User"); > >> > overrides.setProperty("jclouds.swift.tempAuth.headerPass", > >> > "X-Auth-Pass"); > >> > swiftApi = ContextBuilder.newBuilder(provider) > >> > .endpoint(args[1]) > >> > .credentials(identity, credential) > >> > .modules(modules) > >> > .overrides(overrides) > >> > .buildApi(SwiftApi.class); > >> > > >> > *Questions* > >> > 1) Will this behaviour acceptable upstream ? (and what is the > lifecycle > >> > planned for this tempAuthCredentials) > >> > 2) As working on the patch, we have issues to use the variables > injected > >> by > >> > the overrides method. After analysing some parts of the code of > >> > openstack-keystone module, i tried to use @Named and @Inject but > without > >> > success. Is there some doc or some hints on how to do that ? > >> > > >> > Thanks in advance, > >> > > >> > Regards, > >> > > >> > Etienne Carrière > >> > > >> >
