Add configuration key "spring.data.web.pageable.serialization-mode" defaults to DIRECT

[quaff]

see spring-projects/spring-data-commons@5dd7b32

[quaff]

Please hold on until Spring Data Bom 2024.0.0 released.

[wilkinsona]

I think we should provide a better way to do this, perhaps requiring a change in Spring Data, as I'd prefer not to have multiple beans of the same type in the context.

[quaff]

I agree.

[wilkinsona]

@odrotbohm I have a vague recollection that we've already discussed this but I haven't been able to find it.

I guess we could use @ConditionalOnProperty to either auto-configure @EnableSpringDataWebSupport or @EnableSpringDataWebSupport(pageSerializationMode = VIA_DTO). I'm a little hesitant as this approach won't scale as more attributes are added but it would work for now I think.

[odrotbohm]

We ultimately want to nudge people into using VIA_DTO at some point, as that's the better way of serializing Page instances by default. We kept the default at DIRECT for 2024.0.0 to not force applications into the new model, potentially causing them to break their APIs and thus not upgrading. That said, if the Boot team was fine with such a change, we could of course already flip the default, with the users being able to re-instantiate the old behavior by explicitly adding @EnableSpringDataWebSupport(pageSerializationMode = DIRECT) to their application.

Adding a configuration property to flip that switch might be nice, but at the same time, I wonder whether having to use the annotation isn't just enough? On the other hand, I can see this being a nice completion of the spring.data.web.pageable.… property namespace.

Different auto-configurations based on the property look good to me. We have no plans to extend to different rendering strategies, as ultimately, we'd like users to use Spring HATEOAS to properly create standardized response types that support linking when rendering Page instances. Thus, the enum is more of a flag to opt either into a safer way of serializing those (current model), or opt into the legacy way should we decide to flip the default.

[quaff]

@ConditionalOnProperty is not appropriate here, It's just a flag that should be stick to other pageable settings as possible, not like spring.data.redis.client-type which affect creation of other beans.

I'd prefer to not register SpringDataWebSettings bean if pageSerializationMode is default as SpringDataWebAutoConfiguration did, then the @Primary could be removed, here is my proposal: spring-projects/spring-data-commons#3054

[wilkinsona]

I labelled this as blocked but neglected to say why. We're waiting for the outcome of spring-projects/spring-data-commons#3054.

[odrotbohm]

It could be that I am missing something here, but the presence of a SpringDataWebSettings is an indication of a user-provided @EnableSpringDataWebSupport annotation. Shouldn't it be possible to simply guard the creation of the SpringDataWebSettings bean here with the presence of one of the ImportBeanDefinitionRegistrars the annotation registers and of course the lack of a SDWS bean definition itself?

It feels a bit weird to, if the annotation is configured, not forward its configuration default value into downstream configuration setup. That extending into having to write that latter code re-implementing a default that's already set and conveyed through the annotation attribute's value.

[wilkinsona]

Thanks, @odrotbohm.

Adding a configuration property to flip that switch might be nice, but at the same time, I wonder whether having to use the annotation isn't just enough?

As things stand, if you use the annotation, you'll lose our customization of paging and sorting.

Shouldn't it be possible to simply guard the creation of the SpringDataWebSettings bean here with the presence of one of the ImportBeanDefinitionRegistrars the annotation registers.

We already use @EnableSpringDataWebSupport in our auto-configuration when we detect that the user hasn't already used it. Unfortunately, SpringDataWebSettingsRegistar then always registers a SpringDataWebSettings that we can't (easily) replace. We can work around this with two different classes (ignoring fuzzier matching of direct and via-dto:

	@Configuration(proxyBeanMethods = false)
	@EnableSpringDataWebSupport
	@ConditionalOnProperty(name = "spring.data.web.pageable.serialization-mode", havingValue = "direct",
			matchIfMissing = true)
	class EnableSpringDataWebSupportConfiguration {

	}

	@Configuration(proxyBeanMethods = false)
	@EnableSpringDataWebSupport(pageSerializationMode = PageSerializationMode.VIA_DTO)
	@ConditionalOnProperty(name = "spring.data.web.pageable.serialization-mode", havingValue = "via-dto",
			matchIfMissing = false)
	class EnableCustomizedSpringDataWebSupportConfiguration {

	}

spring-projects/spring-data-commons#3054 would remove the need for this little bit of complexity in Boot.