Printable View
Hello!
I got an impression that 1.0.0.RC1 should add the support through access to HttpContext as mentioned in Android-58 (https://jira.springsource.org/browse/ANDROID-58), however this seems not to be the case as I could not find createHttpContext method from HttpComponentsClientHttpRequestFactory.
Any updates when the support will be added?
Thanks!
Hi,
I think it is fully ported. However, createHttpContext is protected, both in spring-framework and spring-android.
For more information how you can use it in Spring, check here:
http://www.baeldung.com/2012/04/16/h...in-spring-3-1/
Hope this helps.
Cheers
For clarity, that link discusses making HTTP Basic Auth requests in RestTemplate, and Spring for Android now has support for Basic Auth included.
I'm sorry, I'm not sure what you mean Roy.
In the referred page it says like this:
"Now, this HttpContext needs to be hooked up to the RestTemplate, so that requests created via the template can benefit from the Basic Authentication support. As mentioned before, this is not an easy as it should be – the entire HttpComponentsClientHttpRequestFactory needs to be subclassed and the createHttpContext method overridden:"
To me this looks like a workaround solution so are there plans to make accessing HttpContext easier so that cookie can be easily set?
Maybe in a similar fashion as here (you can pass context as a parameter to execute -method):
http://hc.apache.org/httpcomponents-...ttpClient.html
Thanks!
In this case it is not a workaround. There are two schools of thought going on here, which may help clarify things. RestTemplate, as with many components in Spring Framework, is designed around a templating concept. If you need more functionality than the "basic" template classes provide, then you should subclass and override/implement the functionality you need in that subclass. In this specific case, createHttpContext(...) is one of those template methods, which has no use outside of subclassing.
The alternative school of thought, would be to implement and expose all the functionality we can in the Spring classes. This would be beneficial in this case, because you would not need to subclass. The potential downside is that those who want to subclass are then left with "baggage" from the template class in the form of functionality they don't need, or worse conflicts.
The main thing to keep in mind is that RestTemplate is a REST framework. REST by definition is supposed to be stateless. This is contradictory to the use of HttpContext, which is probably one reason it was exposed as a subclass hook, and not a public setter method. From the HttpContext javadoc:
Quote:
The primary purpose of the HTTP context is to facilitate information sharing among various logically related components. HTTP context can be used to store a processing state for one message or several consecutive messages. Multiple logically related messages can participate in a logical session if the same context is reused between consecutive messages.