Cannot bootstrap HATEOAS without a default media type enabled

[ingogriebsch]

I currently update Spring HATEOAS Siren and the corresponding samples project to Spring HATEOAS version 1.3.0.

The sample projects are currently not running because of failing tests. These tests fail because I configure the surrounding Boot application in the following way:

@Configuration
@EnableHypermediaSupport(type = {})
class HypermediaConfiguration {

Spinning up the application-context this way is not possible anymore (it worked if using Spring HATEOAS version 1.2.x) because class HypermediaMappingInformationComparator complains about that no Hypermedia type is configured.

Adding my own custom HypermediaType is not possible because it is not possible to enhance and configure the enum that is defined as part of the @EnableHypermediaSupport annotation.

Completely removing @EnableHypermediaSupport(type = {} from the configuration is also not working without further reconfiguration of the application-context because then beans are missing, that are added through the auto-configuration that is triggered through the annotation.

Means that I need to configure one (random) HypermediaType to let the magic sparkle. This is not a problem but should IMO not be neccessary if someone would like to use a custom Hypermedia type.

It would be great if one could configure their custom hypermedia type just like the 'standard' hypermedia types.
Something like

@EnableHypermediaSupport(type = { HypermediaType.of( MediaType.SOME_CUSTOM_MEDIA_TYPE ) })

would be really great! :)

/CC @toedter

[toedter]

While @EnableHypermediaSupport(type = {}) is not working with Spring HATEOAS version 1.3.0,
@EnableHypermediaSupport(type = HAL) still seems to work (at least for my JSON:API tests).
But this (technical) solution is not clean, since we don't want to use HAL in this case.

I would appreciate if custom media type implementations could be treated and used the same way as build-in ones.

[odrotbohm]

I think we can loosen this up to allow an empty array here. Is there a particular reason this is only coming now? The change has been introduced in 1.3 M2 already, i.e. for more than 3 months. I would've hoped that community media type implementations have (at least additional) builds to verify their compatibility with upcoming versions and bring those issues up early.

[toedter]

Sorry, I oversaw this since I still have @EnableHypermediaSupport(type = HAL) in my tests, so they still work with 1.3.0 :)

[ingogriebsch]

I think we can loosen this up to allow an empty array here.

Nice! :)

Do you have something in mind if it will be possible in the future to configure custom mediatype implementations in the same way as the standard mediatype implementations?

Is there a particular reason this is only coming now? The change has been introduced in 1.3 M2 already, i.e. for more than 3 months.

Because 3 months is nothing if you have a regular job and a family with kids! :)

I would've hoped that community media type implementations have (at least additional) builds to verify their compatibility with upcoming versions and bring those issues up early.

Me has not (I don't know how @toedter is dealing with it), at least not at the moment. But I will think about how to do such a check on a regular base.

[toedter]

I usually start testing and porting when Spring HATEOAS does a new release, but I could think of regularly testing against the current HATEOAS snapshot.

[odrotbohm]

Do you have something in mind if it will be possible in the future to configure custom mediatype implementations in the same way as the standard mediatype implementations?

We currently don't. Primarily for the reason that there is no way to properly do that unless we very fundamentally change the artifact structure. We currently ship support for multiple media types and need a mechanism to allow users to define which of them to enable. The annotation based model is pretty convenient but unfortunately cannot incorporate third-party implementations.

We might be able to achieve more commonality in 2.0 by extracting the media type implementations and rather move to a "enable it if it's on the classpath" model.

That said, this should be fixed in 1.3.x and 1.4.x snapshots now.