Yes, it should. Let's continue discussing the implementation details in the pull request. Thanks for submitting the patch!
On 3 January 2017 at 18:26, Etienne Carriere <etienne.carri...@gmail.com> wrote: > 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 >> >> > >> >> >>
