-
Notifications
You must be signed in to change notification settings - Fork 38k
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
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Milestone
Comments
spring-projects-issues
added
the
status: waiting-for-triage
An issue we've not yet triaged or decided on
label
Mar 19, 2019
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
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
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 typesapplication/json
andapplication/*+json
.application/json
is okay, because that is quite specific. However, putting a pattern matcher forapplication/*+json
ahead ofapplication/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 atapplication/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.The text was updated successfully, but these errors were encountered: