I was like 99% sure that the redirect would be followed as Ignasi stated in his first bullet.
I found when using cURL against the endpoint, it actually returns the 302 as stated in the Heat API docs. In addition, when I use my handy Chrome cREST plugin, it follows the redirect and returns the data of interest. Thank you both for the insight! /jd On 9/18/14, 2:58 PM, "Ignasi Barrera" <n...@apache.org> wrote: >Thanks for the pointers Bhathiya! > >It depends on what you want to return: > >* If the redirect must be followed in order to produce the results, >then you shouldn't have to configure anything special, as jclouds will >follow the redirect by default. You just need to make the method in >the API return the object that will be returned as the result of the >redirect. > >* If the redirect must *not* be followed, meaning that the 302 >response is already the response you want, then you'll have to >configure a custom HttpRetryHandler [1] that returns "false" on 302 >return codes for requests to that endpoint. As Bhathiya said, though, >there are several things to be configured: > - The custom retry handler can be configured by overriding the >"bindRetryHandlers" method in the HttpApiModule [2], in a similar way >you do it to configure a custom error handler. >- The configured error handler must be modified to *not set the >exception* in the HttpCommand (as Bhathiya did in his code). This way, >when the response is considered non-retriable, there won't be >exception to propagate and the response will be returned normally [3], >and the configured response parsers will take place, to return the >appropriate Java object. > > >I. > > > >[1] >https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclo >uds/http/HttpRetryHandler.java >[2] >https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclo >uds/rest/config/HttpApiModule.java#L65-L77 >[3] >https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclo >uds/http/internal/BaseHttpCommandExecutorService.java#L125-L138 > >On 18 September 2014 21:18, Bhathiya Supun <hsbath...@gmail.com> wrote: >> Hi Daggett, >> >> I think this is similar to the issue I had with google cloud storage >> resumable uploads where expected response was 308 . these may help >> you >> Problem is jclouds consider any response other than 2xx as a problem. >> >> >>https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jcl >>ouds/http/internal/BaseHttpCommandExecutorService.java#L104 >> >> I had to override redirectRetryHandler with >> >>https://github.com/jclouds/jclouds-labs-google/blob/master/google-cloud-s >>torage/src/main/java/org/jclouds/googlecloudstorage/handlers/GoogleCloudS >>torageRedirectRetryHandler.java >> >> Also avoiding setException call >> >>https://github.com/jclouds/jclouds-labs-google/blob/master/google-cloud-s >>torage/src/main/java/org/jclouds/googlecloudstorage/handlers/GoogleCloudS >>torageErrorHandler.java >> >> I also had lot of troubles with this untill nacx help me :) >> >> >> On 19 September 2014 00:10, Jeremy Daggett >><jeremy.dagg...@rackspace.com> >> wrote: >> >>> Hi devs, >>> >>> I have a situation where the OpenStack Heat API [1] returns a 302 >>>redirect >>> for finding a particular stack: >>> >>> /v1/{tenant_id}/stacks/{stack_name} >>> >>> This is new territory for the OpenStack APIs and I am not clear on how >>>to >>> handle it. It looks like the various HTTP annotations [2] are used in >>> binding the error handlers, so do I just handle it in the switch >>>statement >>> of the error handler? >>> >>> Any help is appreciated! >>> >>> /jd >>> >>> [1] http://developer.openstack.org/api-ref-orchestration-v1.html#stacks >>> [2] >>> >>>https://github.com/jclouds/jclouds/tree/master/core/src/main/java/org/jc >>>louds/http/annotation >>>
