spring-cloud / spring-cloud/spring-cloud-gateway

New starters in 4.3 should not depend on spring-boot-properties-migrator

Open
#4,022 2 comments 0 reactions 1 assignee View on GitHub

@spencergibb is already working on this.

Since Jan 12, 2026.

waiting-for-triage
Dominant language
Java
Stars
4.9k
Forks
3.5k
Avg merge
20h 57m
Merged PRs (30d)
8

Description

The new modules spring-cloud-starter-gateway-server-webflux and spring-cloud-starter-gateway-server-webmvc both depend on spring-boot-properties-migrator.

This is unexpected from a user point of view, since

  • this should be used only temporarily to help with property migration,
  • this is probably a lesser-known tool that people are not aware of,
  • the documentation says “Remember to remove the dependency when your migration is complete.”,
  • those are the new modules, so one wouldn’t expect them to work with the old properties,
  • the Spring Cloud 2025.0 Release Notes explicitly specify that the dependency should be added if desired:

Migration to new property prefixes to match the new module names: #3361, #3362, #3363, #3647. Use spring-boot-properties-migrator to support the deprecated prefixes.

People might thus not notice it – especially in production environments where operations might not be looking for the corresponding warning in the logs.

Even worse, since cloud.gateway.server.webflux.routes is a list, if you mix the old and new prefixes, the deprecated properties will override routes from the new prefix (since the properties are migrated by index position).

People who completed the migration (and are thus using the new modules) shouldn’t need this dependency, right?

I think it would thus be better to leave the choice to end users, otherwise they have to put an exclusion for it.

(I initially wrote this in https://github.com/spring-cloud/spring-cloud-release/issues/452#issuecomment-3633234197 but I guess it was overlooked as the ticket was already closed)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.