by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:00

    odrotbohm on master

    #1349 - Fix reference to Spring… (compare)

  • 09:47

    odrotbohm on master

    #1348 - Fix spring-next build p… (compare)

  • 09:36
    odrotbohm milestoned #1316
  • 09:36
    odrotbohm demilestoned #1316
  • 09:36
    odrotbohm milestoned #1282
  • 09:36
    odrotbohm demilestoned #1282
  • 09:36
    odrotbohm milestoned #1274
  • 09:36
    odrotbohm demilestoned #1274
  • 09:36
    odrotbohm milestoned #1260
  • 09:36
    odrotbohm demilestoned #1260
  • 09:36
    odrotbohm milestoned #1243
  • 09:36
    odrotbohm demilestoned #1243
  • 09:36
    odrotbohm demilestoned #1240
  • 09:36
    odrotbohm milestoned #1240
  • 09:36
    odrotbohm milestoned #1237
  • 09:36
    odrotbohm demilestoned #1237
  • 09:36
    odrotbohm milestoned #1221
  • 09:36
    odrotbohm demilestoned #1221
  • 09:36
    odrotbohm milestoned #1087
  • 09:36
    odrotbohm demilestoned #1087
Ingo Griebsch
@ingogriebsch
But I would prefer to support the recent version.
Greg L. Turnquist
@gregturn
Not sure that's important. 1.0.x currently supports Spring Boot 2.1, which won't be supported for much longer, per their updated support policy.
Ingo Griebsch
@ingogriebsch
Therefore I'm planning to update to 1.1.1.RELEASE as soon as available.
And to update to 1.2.0.RELEASE as well!
Greg L. Turnquist
@gregturn
I'm shooting to release 1.1.1.RELEASE this week. Wanted to get some of the keys items merged.
Ingo Griebsch
@ingogriebsch
Good to know! Will update my project as soon as the new version is available.
Greg L. Turnquist
@gregturn
Spring HATEOAS 1.1.1.RELEASE is out!
Share and enjoy!
Ingo Griebsch
@ingogriebsch
Congrats! :)
Kai Toedter
@toedter
Great!
Puspender
@Puspendert
Screenshot 2020-08-01 at 6.52.24 PM.png

I upgraded Spring from 0.x to 1.x which has some major updation in package and class names.
With the older versions, Autowire EntityLinks was working fine but now intellij IDEA is giving compilation warning warning.

Anyone experienced the same?

No beans of EntityLinks found. I have @EnableHypermediaSupport(type = EnableHypermediaSupport.HypermediaType.HAL) enable, as I told it was not an issue with 0.x version
Puspender
@Puspendert
Update: Seems like this is issue with Intellij IDEA. Logged the EntityLinks instance and it’s non-null.
Kai Toedter
@toedter
When you create a custom media type, is it possible to register it as default? I mean, can it be delivered when no accept header is present?
Greg L. Turnquist
@gregturn
@toedter Not yet. There is some Spring Boot stuff at play that will get in your way. Since HAL was the one-and-only type for a LONG time, the autoconfiguration stuff written leans that way. If you look for HypermediaAutoConfiguration, you can find the gist of what Boot is up to, and possibly swap it out for something else.
@Puspendert If you're using Boot, then you shouldn't need @EnableHypermediaSupport(HAL). That's what Boot does automatically whenever you put spring-hateoas on the classpath. Just take a peak at HypermediaAutoConfiguration to see exactly WHAT Boot is doing (so you don't have to repeat it).
Puspender
@Puspendert
👍

No beans of EntityLinks found. I have @EnableHypermediaSupport(type = EnableHypermediaSupport.HypermediaType.HAL) enable, as I told it was not an issue with 0.x version

Just to inform you guys, it’s a bug in IDEA
https://youtrack.jetbrains.com/issue/IDEA-243044

Kai Toedter
@toedter
Thx Greg, I would consider this a great feature, should I put an issue in the Github issue tracker?
Kai Toedter
@toedter
I just figured out, that at least my implementation of JSON:API will become the default, when a dependency is defined. But I still like the idea to make this configurable in the future...
Ingo Griebsch
@ingogriebsch
I observe a similar behavior
If I add my library to a Spring Boot service and @EnableHypermediaSupport(type = HAL) and ask for the following way I get
  • application/hal+json = HAL
  • application/vnd.siren+json = Siren
  • application/json = Siren
Ingo Griebsch
@ingogriebsch
But if I add my library to a Spring Boot service and @EnableHypermediaSupport(type = HAL) and spring.hateoas.use-hal-as-default-json-media-type=false in application.properties and ask for the following I get
  • application/hal+json = HAL
  • application/vnd.siren+json = Siren
  • application/json = raw JSON
Greg L. Turnquist
@gregturn
Yeah, spring.hateoas.use-hal-as-default-json-media-type is a VERY limited knob on Spring Boot. It's a hardcoded path to apply HAL to application/json and nothing else.
Ingo Griebsch
@ingogriebsch
But with a custom mediatype on the classpath it is not applying HAL to application/json anymore. Or Postman is kidding me...
Ingo Griebsch
@ingogriebsch
@gregturn another question...
After removing the Siren MediaTypeConfigurationProvider implementation from my library I now have the problem to support that someone wants to implement some @WebMvcTest. Before, the Siren MediaTypeConfigurationProvider implementation was respected, the Siren HypermediaMappingInformation implementation was loaded and therefore the media-type was available during the test execution.
The currently used auto-configuration approach is not triggered per se. And because the Siren HypermediaMappingInformation implementation is package private, one cannot simply @Import it (and actually I'd like to keep it that way).
Using @ComponentScan with de.ingogriebsch.hateoas.siren is currently my only idea to initialize the Siren HypermediaMappingInformation implementation during the test execution. But this looks not like an ideal solution.
You can check the current test implementation in my sample project: https://github.com/ingogriebsch/sample-spring-hateoas-siren.
Any hint/idea how to support such tests in a more discreet way?
/CC @toedter
This is how we test a custom media type (FRODO) injected into a WebMvcTest.
Ingo Griebsch
@ingogriebsch
Okay, Thanks! I think I understand. But this is not what I want a user of the library should need to do to implement a @WebMvcTest for a single controller using the custom media type.
I will think about how I can provide a more easy way.
Greg L. Turnquist
@gregturn
Ohh, sorry. I thought you meant for YOUR tests.
Ingo Griebsch
@ingogriebsch
At the moment these are MY tests, contained in the simple sample project using the custom media type.
But I believe that the people which are using the library in a Spring Boot project also want to test the behavior on the controller layer.
Like me in the sample project. And therefore I would like to provide an easy way to implement such tests.
Greg L. Turnquist
@gregturn

Something I can immediately think of is some @Configuration class you offer that's inside your package...

@Congratulation
public class SirenConfiguration {

    @Bean
    HypermediaMappingInformation sirenMediaType() {
        return new SirenMediaTypeConfiguration();
    }
}

This class can ALSO be leveraged into a @EnableSiren annotation that simply imports SirenConfiguration, yeah?

Ingo Griebsch
@ingogriebsch
Probably something like this. I'm again at the point there I think that providing a separate auto-configuration to integrate the custom media-type into Spring Boot is the way to go.
Greg L. Turnquist
@gregturn
Agreed. And if you put the Spring Boot bits in a separate project, that would make sense. But it's an extra cost to maintain that. I would favor that, since it's not hard to set up a multi-module project within a single repository via maven.
Ingo Griebsch
@ingogriebsch
@gregturn May I ask why a custom media-type should not use and implement MediaTypeConfigurationProvider anymore? It worked like a charm. The only open 'problem' was, how to configure, which (custom) media-types to enable. ;)
Greg L. Turnquist
@gregturn

It doesn't really do what you think it's doing. @EnableHypermediaSupport can ONLY pick up media types IT knows about, like HAL and UBER+JSON. Your custom media types don't show up there, hence the supports operation only acts as expected for our out-of-the-box types.

Whether or not you have that Provider interface implemented, all HypermediaMappingInformation beans will get picked up, registered, and applied to WebMVC/WebFlux/WebClient/RestTemplate/etc.

The only reason for the Provider interface is to give us a chance to NOT register, say UBER+JSON, when it's not explicitly enabled. Hence, no need to instruct everyone to implement it. Instead, define your HypermediaMappingInformation type, create the bean, add it to the application context, and we'll take it from there.

Now if your media type supports affordances, you need to extra glue regarding AffordanceModelFactory. But not all media types do.
Ingo Griebsch
@ingogriebsch
Okay, Thanks! I think I understand. And I don't wanted to start a discussion about your decision. Only want to understand why you decided that way. :)
Greg L. Turnquist
@gregturn
I understand. Frankly, it took a few chats between me and Ollie (and some horrible testing) to realize the real issue of all this.
Ingo Griebsch
@ingogriebsch
@gregturn: Because the topic 'MediaTypeConfigurationProvider' does not let me go and because it keeps jumping around in my head...
I ask myself all the time why @EnableHypermediaSupport defines an own HypermediaType? Would it not have been possible to allow to configure the desired type(s) via org.springframework.http.MediaType? This would have made it possible to configure both the out-of-the-box types and the custom types in the same way. A custom type would still have to implement MediaTypeConfigurationProvider and use the spring.factories, but the advantage would be that all HATEOAS implementations could be configured and initialized in the same way. Then it would not be necessary for a custom type to implement and provide a separate (auto) configuration.
I probably overlook something or think too easily. And it's not that I don't want to provide an (auto-)configuration. I just wanted to share my thoughts with you. :)
Oliver Drotbohm
@odrotbohm

The type attribute in @EnableHypermediaType can not be a Spring MediaType as that is a class and not an enum. We need to constrain the values as otherwise you could put arbitrary media types there that we don't even support. I.e. just making that attribute a String would not have worked. I guess you can argue that this would be detectable at runtime and could be rejected but unfortunately that API is now out in the wild and we're gonna have to support it until at least 2.0.

It has come up as an issue from a library architecture point of view a couple of times as well and it's very likely we fix that for 2.0.

We've also thought about making all media type implementations dedicated JARs and rely on classpath detection at runtime but that would then put some burden on the users to assemble the right set of JARs. We could probably solve that by keeping the Boot starter to basically produce the same setup as now but again that's something that's wider ranging.
Kai Toedter
@toedter
I would love to see a future approach so that build-in and custom media types would be citizens of the same class (of course first class :))
Greg L. Turnquist
@gregturn
Agreed @toedter.