Repository navigation
Provide a way to specify a timeout in Rest Services #651
Description
Activity
What would be the generated code ?
Something like this?
ClientHttpRequestFactory requestFactory = restClient.getRestTemplate().
getRequestFactory();
if (requestFactory instanceof SimpleClientHttpRequestFactory) {
Log.d("HTTP", "HttpUrlConnection is used");
((SimpleClientHttpRequestFactory) requestFactory).
setConnectTimeout(timeout);
((SimpleClientHttpRequestFactory) requestFactory).setReadTimeout(timeout
);
} else if (requestFactory instanceof HttpComponentsClientHttpRequestFactory)
{
Log.d("HTTP", "HttpClient is used");
((HttpComponentsClientHttpRequestFactory) requestFactory).
setReadTimeout(timeout);
((HttpComponentsClientHttpRequestFactory) requestFactory).
setConnectTimeout(timeout);
}On Fri, Jul 5, 2013 at 9:38 AM, Yoann Delouis notifications@github.comwrote:
What would be the generated code ?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/651#issuecomment-20522145
.Frank D. Martínez M.
This point has been discussed on the google group
I'm still thinking that a field in each
@Get,@Post, etc.. annotations is the best choice for end users.I think it should be done at the
@Restannotation level because you set the timeout to theRestTemplate. (Like interceptors and converters).
Moreover, how would you restore the default behaviour for other methods annotated with@Get,@Post, ...
Then, if you set interceptors, the requestFactory is anInterceptingClientHttpRequestFactoryand it has no method to set a timeout.The only problem with this solution is to set different timeout on some methods. I agree that timeout is set on
RestTemplatebut it also odd to create a new@Restannotated interface just for having different timeout. What do you think ?I don't know if it's a common use case to set different timeouts on methods of the same rest service...
And it seems that Spring thought like me since they set the timeout atRestTemplatelevel ;-)
Then, how do you solve the incompatibility between timeout and interceptors ?Another way is to create an injectable Template, something like:
@RestTemplateFactory
class MyCustomRestTemplateFactory {
public RestTemplate getInstance() {
....
}
}So we can inject it at method level
@get("/Myresource")
@TemplateProvider(MyCustomRestTemplateFactory.class)
public Event getEvent();MyCustomRestTemplateFactory should be a managed singleton.
What do you think?
On Fri, Jul 5, 2013 at 10:08 AM, Damien notifications@github.com wrote:
The only problem with this solution is to set different timeout on some
methods. I agree that timeout is set on RestTemplate but it also odd to
create a new @rest annotated interface just for having different timeout.
What do you think ?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/651#issuecomment-20523571
.Frank D. Martínez M.
To handle very special cases, I had an idea :
We could change a bit the way rest services are done. The annotations would be :@Restwith only one parameter rootUrl.@Get,@Post, etc. are the same as before.@RestTemplatewith parameters : converters, interceptors and timeout.
@RestTemplatecan be placed on both the interface and the methods. The annotation@RestTemplateon the interface defines the defaultRestTemplateused in the service. And, if a method is annotated with@RestTemplate, a newRestTemplateis created in the method and used instead of the default one.
If you don't want to break the API, we could just add the annotation
@RestTemplateon methods and add the parametertimeoutto the annotation@RestThis would enable us to handle special cases without creating a new interface. And we could explain that the parameter timeout is ignored if interceptors are specified.
Tell me what you think about this.
Sounds really good! also RestTemplate instances can be cached composing a
key with @RestTemplate fields. but maybe it is not necessary.On Sun, Jul 7, 2013 at 6:18 AM, Yoann Delouis notifications@github.comwrote:
To handle very special cases, I had an idea :
We could change a bit the way rest services are done. The annotations
would be :- @rest with only one parameter rootUrl.
- @get, @post, etc. are the same as before.
- @RestTemplate with parameters : converters, interceptors and
timeout. @RestTemplate can be placed on both the interface and the
methods. The annotation @RestTemplate on the interface defines the
default RestTemplate used in the service. And, if a method is
annotated with @RestTemplate, a new RestTemplate is created in the
method and used instead of the default one.
This enables us to handle special cases without creating a new interface.
And we can explain that the parameter timeout is ignored if interceptors
are specified.Tell me what you think.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/651#issuecomment-20569291
.Frank D. Martínez M.
We need to stay focused in the main purpose of AA : removing boiler plate code for common cases.
Each@Restannotated interface provides an easy way to implement rest-services for a root url (ie: domain). It's common to have an unique timeout for all calls to a domain. So, let's keep it simple and just add atimeoutfield to@Restannotation as you suggested before. All other tricky cases can be handled by getting the RestTemplate instance."getting the RestTemplate instance" is "boiler plate code for common cases"
On Mon, Jul 8, 2013 at 9:01 AM, Damien notifications@github.com wrote:
We need to stay focused in the main purpose of AA : removing boiler plate
code for common cases.
Each @rest annotated interface provides an easy way to implement
rest-services for a root url (ie: domain). It's common to have an unique
timeout for all calls to a domain. So, let's keep it simple and just add a
timeout field to @rest annotation as you suggested before. All other
tricky cases can be handled by getting the RestTemplate instance.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/651#issuecomment-20607101
.Frank D. Martínez M.
@mnesarco I don't think this is the subject. "Getting the RestTemplate instance to set different timeouts for different methods" is not a common case.
You were basically asking the question "Is setting different timeouts on different methods of a web service a common case". @yDelouis said before it's not, @DayS agreed.
I agree too. If there is a real difference between timeouts, it's probably a different web services (file download, statistics computation or whatever) in which all method needs a bigger timeout.
Putting the timeout attribute at the
@Restannotation level sounds good to me.Instead of a parameter which set the timeout, we could inject a
ClientHttpRequestFactoryjust as we are doing for the interceptors.
For one of my apps, I need to inject anotherClientHttpRequestFactoryto allow every certificates using https, and I don't want to set it manually.To change the timeout, you'll just need to create a subclass of
HttpComponentsClientHttpRequestFactoryin which you set the timeout in the constructor and put it in the parameterrequestFactoryof the annotation@Rest.How is this issue going? I've created an Issue relating this: #902
I think we can close this issue as we can now inject a custom
RequestFactoyCreate a custom RequestFactory:
import org.springframework.http.client.SimpleClientHttpRequestFactory; public class CustomRequestFactory extends SimpleClientHttpRequestFactory { public CustomRequestFactory() { setConnectTimeout(2000); setReadTimeout(2000); } }And put to
@Restannotation:@Rest(requestFactory = CustomRequestFactory.class)@Restis part of the AndroidAnnotations REST library.Sorry, this is AndroidAnnotations' repository. For Spring Boot questions, go to the relevant Spring Boot channels.
It would be nice if we can set the timeout in Rest method declarations. Something like:
or
or