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.

Sign up for GitHub

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

Jump to bottom

HAL not set as default in 1.2.0 #2147

Closed
lazee opened this issue Dec 14, 2014 · 3 comments
Closed

HAL not set as default in 1.2.0 #2147

lazee opened this issue Dec 14, 2014 · 3 comments
Labels
type: bug A general bug type: regression A regression from a previous release
Milestone
1.2.1

Comments

@lazee
Copy link

lazee commented Dec 14, 2014

In Spring Boot 1.1.10 the default hateoas format is HAL as long as spring-hateoas is included in the classpath (According to the doc and real life experience). This is no longer the case and I had to add both @EnableWebMvc and @EnableHypermediaSupport(type= {EnableHypermediaSupport.HypermediaType.HAL}) to my application in order to get HAL.

Is this intended behaviour or a bug? Looking at spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/hateoas/HypermediaAutoConfiguration.java it seems a bug has been fixed for another issue (#1729). Would this fix also fix this HAL problem?
@philwebb philwebb added the type: bug A general bug label Dec 14, 2014
@philwebb philwebb added this to the 1.2.1 milestone Dec 14, 2014
@philwebb philwebb added the type: regression A regression from a previous release label Dec 15, 2014
@philwebb
Copy link
Member

I'm seeing some interesting differences between 1.1.10 and 1.2.0 but it does appear to me that HAL support is enabled. I've added a sample application and a test to this branch. The difference between 1.1.x and master seems to be that the accept header must be set to application/hal+json in order to get the correct response. With 1.1.x a header of application/json also seemed to return _links in the json.

Do you have a sample application that demonstrates the issue? Have you also tried setting the accepts header in the request?

@philwebb
Copy link
Member

/cc @olivergierke and @wilkinsona who are much more familiar with that code.

@philwebb philwebb added the status: waiting-for-feedback We need additional information before we can continue label Dec 15, 2014
@wilkinsona
Copy link
Member

I believe this problem was caused by the fix for #1729. Here's what's happening:

In 1.2.0 it's only the TypeConstrainedMappingJackson2HttpMessageConverter that has the HATEOAS mixins registered with its ObjectMapper. This converter only handles application/hal+json. In 1.1.10 both the TypeConstrainedMappingJackson2HttpMessageConverter and a MappingJackson2HttpMessageConverter have the mixins registered with their ObjectMapper. It's the MappingJackson2HttpMessageConverter converter that handles the application/json request.

In 1.1.10 the TypeConstrainedMappingJackson2HttpMessageConverter and the first MappingJackson2HttpMessageConverter share an ObjectMapper and, therefore, share the same mixin configuration.

In the absence of an ObjectMapper bean, JacksonAutoConfiguration creates a @Primary ObjectMapper. In 1.2.0 it's configured to be auto-configured before HypermediaAutoConfiguration so its ObjectMapper is created and used by MappingJackson2HttpMessageConverter. When
TypeConstrainedMappingJackson2HttpMessageConverter is created it's configured to use the separate HAL ObjectMapper hence the different mixin configuration. In 1.1.10, HypermediaAutoConfiguration goes first and registers the HAL ObjectMapper bean. This prevents JacksonAutoConfiguration from creating its ObjectMapper which causes the MappingJackson2HttpMessageConverter and TypeConstrainedMappingJackson2HttpMessageConverter to share ObjectMapper instances and to, therefore, also share the mixin configuration.

@philwebb philwebb removed the status: waiting-for-feedback We need additional information before we can continue label Dec 16, 2014
@wilkinsona wilkinsona mentioned this issue Sep 2, 2015
Closed
@wilkinsona wilkinsona mentioned this issue Sep 24, 2015
Closed
wilkinsona added a commit that referenced this issue Sep 24, 2015
@wilkinsona
Simplify Jackson-related auto-configuration for HATEOAS and Data REST
c55900b 
This commit simplifies the Jackson-related auto-configuration that’s
applied when Spring HATEOAS and Spring Data REST are on the classpath.

Previously, Boot used Jackson2HalModule to apply the HAL-related
ObjectMapper configuration to the context’s primary ObjectMapper. This
was to allow HAL-formatted responses to be sent for requests accepted
application/json (see gh-2147). This had the unwanted side-effect of
polluting the primary ObjectMapper with HAL-specific functionality.
Furthermore, Jackson2HalModule is an internal of Spring HATEOAS that
@olivergierke has asked us to avoid using.

This commit replaces the use of Jackson2HalModule with a new approach.
Now, the message converters of any RequestMappingHandlerAdapter beans
are examined and any TypeConstrainedMappingJackson2HttpMessageConverter
instances are modified to support application/json in addition to their
default support for application/hal+json. This behaviour can be disabled
by setting spring.hateoas.use-hal-as-default-json-media-type to false.
This property is named after Spring Data REST’s configuration option
which has the same effect when using Spring Data REST. The new property
replaces the old spring.hateoas.apply-to-primary-object-mapper property.

Previously, when Spring Data REST was on the classpath,
JacksonAutoConfiguration would be switched off resulting in the context
containing multiple ObjectMappers, none of which was primary.

This commit configures RepositoryRestMvcAutoConfiguration to run after
JacksonAutoConfiguration. This gives the latter a chance to create its
primary ObjectMapper before the former adds its ObjectMapper beans to
the context.

Previously, the actuator’s hypermedia support assumed that the
HttpMessageConverters bean would contain every HttpMessageConverter
being used by Spring MVC. When Spring HATEOAS is on the classpath this
isn’t the case as it post-processes RequestMappingHandlerAdapter beans
and adds a TypeConstrainedMappingJackson2HttpMessageConverter to them.
This wasn’t a problem in the past as the primary ObjectMapper, used by a
vanilla MappingJackson2HttpMessageConverter, was configured with Spring
HATEOAS’sJackson2HalModule. Now that this pollution has been tidied up
the assumption described above no longer holds true. MvcEndpointAdvice,
which adds links to the actuator’s json responses, has been updated
to look at the HttpMessageConverters of every
RequestMappingHandlerAdapter when it’s trying to find a converter to
use to write a response with additional hypermedia links.

Integration tests have been added to spring-boot-actuator to ensure
that the changes described above have not regressed the ability to
configure its json output using spring.jackson.* properties (see
gh-1729).

Closes gh-3891
@wilkinsona wilkinsona mentioned this issue Sep 5, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: bug A general bug type: regression A regression from a previous release
Projects
None yet
Milestone
1.2.1
Development

No branches or pull requests
3 participants
@lazee @philwebb @wilkinsona