Custom async HandlerMethodReturnValueHandler should work with @ResponseBody [SPR-13083]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-13083 and commented

Currently custom return value handlers are registered after built-in ones. This works fine except when creating a custom return value handler to support a DeferredResult-like return type, for example the RxJava rx.Observable, in which case the custom return value handler should be called first and then when the async value is computed the @ResponseBody return value handling should take place.

---

Affects: 4.1.6

Referenced from: commits 210e10c

0 votes, 5 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

A possible workaround:

@Configuration
public class Config {

	@Autowired
	private RequestMappingHandlerAdapter handlerAdapter;

	@PostConstruct
	public void init() {
		List<HandlerMethodReturnValueHandler> handlers = new ArrayList<>(handlerAdapter.getReturnValueHandlers());
		handlers.add(0, new ObservableReturnValueHandler());
		handlerAdapter.setReturnValueHandlers(handlers);
	}

}

[spring-projects-issues]

Diego Magalhaes commented

Hey @rstoyanchev couldn't you just use Ordered annotation?

[spring-projects-issues]

Rossen Stoyanchev commented

Ordered can provide a degree of control but explicit ordering would not be easy to manage. Here we are discussing custom handlers being ahead of annotation-based. It would be fragile to express that with an explicit index. It seems be more a question of where in the relative order should you be? Spring Security's filter chain has a similar situation which it solves with filter aliases relative to which you can add filters. I'm not sure we need to go as far to solve this issue.

[spring-projects-issues]

Rossen Stoyanchev commented

Modified title to better reflect the problem, rather than indicate a solution.

[spring-projects-issues]

Diego Magalhaes commented

Great indeed, thanks for the explanation and the Aliases link, I'll read it right away.

[spring-projects-issues]

Rossen Stoyanchev commented

This should now be fixed in the 4.2 snapshot. To make use, implement AsyncHandlerMethodReturnValueHandler (rather than HandlerMethodReturnValueHandler) and that will ensure the handler is considered ahead of other non-async handlers. Commit 210e10.