Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Current definition of the Formatter interface might force blocking in WebFlux [SPR-15551] #20110

spring-projects-issues opened this issue May 15, 2017 · 1 comment
in: web status: declined


Copy link

@spring-projects-issues spring-projects-issues commented May 15, 2017

Daniel Fernández opened SPR-15551 and commented

In one of the Thymeleaf sample applications using WebFlux, I have a Formatter like this:

public class VarietyFormatter implements Formatter<Variety> {
    public Variety parse(final String text, final Locale locale) throws ParseException {
        final Integer varietyId = Integer.valueOf(text);
        // There is no Formatter API yet that allows us to return a Publisher, so we need to block
        return this.varietyService.findById(varietyId).block();


This is what I think could be a quite common pattern: a Formatter being used for transforming
a PK (perhaps coming from a form field) into a complete entity object, coming from the database.

The problem is, the service method that this needs to call is reactive:

public Mono<Variety> findById(final Integer id) {

So either the Formatter#parse() method calls .block(), or it returns Mono<Variety>. But in the latter case, that would mean changing the formatter class's specification to:

public class VarietyFormatter implements Formatter<Mono<Variety>> {

And this would force us to block at the Formatter#print() method:

public String print(final Mono<Variety> object, final Locale locale) {
    final Variety variety = object.block();
    return (variety != null ? variety.getId().toString() : "");

Why not return Mono<String> there? because the Formatter<T> interface extends from Printer<T>, and the Printer#print(...) method is defined as:

String print(T object, Locale locale);

So it seems to me that there is no way to support this scenario in a non-blocking manner right now…

Affects: 5.0 RC1

@spring-projects-issues spring-projects-issues added status: waiting-for-triage type: enhancement in: web and removed type: enhancement labels Jan 11, 2019
Copy link

@bclozel bclozel commented Feb 18, 2022

Sorry for replying so late.
I don't think the Formatter interface was meant for such use cases involving remote I/O. This resolution should be done at a different stage / using other infrastructure. We don't plan on offering a reactive variant for this contract at the moment. I'm declining this issue as a result.

@bclozel bclozel closed this as completed Feb 18, 2022
@bclozel bclozel added status: declined and removed status: waiting-for-triage labels Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: web status: declined
None yet

No branches or pull requests

2 participants