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

Custom WebFlux encoders/decoders are placed below defaults #22612

Closed
gregturn opened this issue Mar 19, 2019 · 0 comments
Closed

Custom WebFlux encoders/decoders are placed below defaults #22612

gregturn opened this issue Mar 19, 2019 · 0 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@gregturn
Copy link
Contributor

When registering custom encoders and decoders to handle media types (e.g. application/hal+json) inside https://github.com/spring-projects/spring-hateoas/blob/master/src/main/java/org/springframework/hateoas/config/WebClientConfigurer.java, they are placed too far down to get read.

The default decoders includes a DecoderHttpMessageReader with mime types application/json and application/*+json.

application/json is okay, because that is quite specific. However, putting a pattern matcher for application/*+json ahead of application/hal+json causes the default one to always get selected. And this will happen for any other media type that registers a JSON-based media type (e.g. HAL-FORMS at application/prs.hal-forms+json).

I don't know if this means custom encoders and decoders should be moved to the front, or if something more sophisticated is needed, like putting wildcard-based patterns after non-wildcard-based ones.

For now, it forces us to disable the default registry just to get operational, which in turn causes headache for downstream projects like Spring Cloud Sleuth that are having their own WebClient post processing trounced by Spring HATEAOS.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 19, 2019
@rstoyanchev rstoyanchev added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 19, 2019
@rstoyanchev rstoyanchev added this to the 5.2 M1 milestone Mar 19, 2019
gregturn added a commit to spring-projects/spring-hateoas that referenced this issue Mar 21, 2019
Spring Framework 5.1 puts custom encoders and decoders in the wrong place, so Spring HATEOAS can't properly register with WebFlux. To make Spring HATEOS media types work requires overriding features that break other toolkits, like Spring Cloud Sleuth. However, in Spring Framework 5.2, this is no longer needed, so we need only disable the registry when Spring Framework 5.1 is on the classpath.

Related issues: #885, spring-projects/spring-framework#22612
gregturn added a commit to spring-projects/spring-hateoas that referenced this issue Mar 22, 2019
Thanks to spring-projects/spring-framework#22612, Spring HATEAOAS no longer has to disable the default registry of encoders and decoders to get its custom components to work.

Related issues: #885
gregturn added a commit to spring-projects/spring-hateoas that referenced this issue Mar 23, 2019
Thanks to spring-projects/spring-framework#22612, Spring HATEAOAS no longer has to disable the default registry of encoders and decoders to get its custom components to work.

Related issues: #885
gregturn added a commit to spring-projects/spring-hateoas that referenced this issue Apr 3, 2019
Thanks to spring-projects/spring-framework#22612, Spring HATEAOAS no longer has to disable the default registry of encoders and decoders to get its custom components to work.

Related issues: #885, spring-projects/spring-framework#22612
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants