Enable the Siren hypermedia without the usage of the internal Spring HATEOAS SPI

[ingogriebsch]

We currently enable the Siren hypermedia type as soon as the library is available on the classpath. But it is the only way until spring-projects/spring-hateoas#1304 is solved.

Related issues:

• When EnableHypermediaSupport is empty, enable all hypermedia types. spring-projects/spring-hateoas#1265
• When @EnableHypermediaSupport has no types, only enable user-defined media types. spring-projects/spring-hateoas#1060

Check the comments of the mentioned issues as well to understand how to integrate the custom mediatype (how about spring.factories, HypermediaMappingInformation, MediaTypeConfigurationProvider?).

[gregturn]

@ingogriebsch

Long story short, you only need to implement HypermediaMappingInformation and ensure that bean is on the classpath. You can drop your implementation of MediaTypeConfigurationProvider and spring.factories.

This should also be easy to test.

[gregturn]

As for "is SIREN wanted", I would use its existence on the classpath as the signal of it being wanted.

spring-projects/spring-hateoas#1304, in its original form, was not going to have an enabling signal. We ONLY do that for the provided media types inside Spring HATEOAS because those types are ALWAYS on the classpath.

[ingogriebsch]

@gregturn Thanks for the hints!

I need to think a moment about how to handle the (auto-)configuation part. I also don't like to use @component. But using a spring.factories file inside the library would IMO mix up responsibilities a little bit. spring.factories is a Spring Boot mechanism as far as I understand. But the library itself is not (the same counts for Spring HATEOAS itself, correct?) and should therefore be usable without Spring Boot. So referencing the @Configuration class which implements HypermediaMappingInformation in a spring.factories which is part of the library itself feels... not right.

Therefore introducing an auto-configuration and/or starter jar is maybe the way to go?! 🤔

[gregturn]

Actually, spring.factories is pure Spring Framework.

To prove my point, Spring HATEOAS is consumed by Spring Boot, not the other way around. Spring HATEOAS doesn't have the luxury of using some of Boot's tools and instead leans on lower level stuff.

[ingogriebsch]

Ah, because SpringFactoriesLoader is part of the Core framework!

Nevertheless, adding org.springframework.boot.autoconfigure.EnableAutoConfiguration to the spring.factories in such a library IMO results in mixing up the used frameworks and the responsibilities. That is what I wanted to say and what I'm struggling with.