Repository navigation
Support Spring Cloud InetUtils for client registration - #4600
myProjectsRavi wants to merge 2 commits into
Conversation
erikpetzold
left a comment
There was a problem hiding this comment.
I did not yet have a look at the changes in detail yet, but please clean up the PR
|
Thanks for picking this up — #1323 is a real gap and the intent here is right. I went through the diff and the linked issue, and one functional bug stands out along with a few smaller items. Happy to help with any of it. The InetUtils branch never executesIn Method m = utils.getClass().getMethod("findFirstNonLoopbackHostInfo");
Object host = m.invoke(utils);
if (host instanceof String && StringUtils.hasText((String) host)) {
Checked 4.1.4, 4.2.0, 4.3.0, 5.0.1 and 5.0.3 — all Likely shapeOn #1323 @joshiste suggested "a special ApplicationFactory that will be autoconfigured when the InetUtils are present", since the client also has to work without Spring Cloud. Smaller items
If it's useful, I'm glad to open a superseding PR in the shape above (conditional |
Use conditional servlet and reactive factories for host resolution. Keep Spring Cloud optional and preserve existing URL handling. Closes codecentric#1323.
b1073ce to
2aba8e1
Compare
Exclude InetUtils auto-configuration from tests that expect the default local host lookup.
|
Addressed the review feedback and rebased this PR onto the current master. |
Use Spring Cloud's
InetUtilsto select the local registration address when anInetUtilsbean is available, so clients can honorspring.cloud.inetutils.*settings.findFirstNonLoopbackAddress()directly.Validation:
./mvnw -B -ntp -DdisableSpringSnapshots -pl spring-boot-admin-client -am clean verifypasses on Java 17: 124 tests, no failures, errors, or skipped tests. Checkstyle, Spring Java Format, and Javadoc generation pass. The existing registration integration tests explicitly use the default factories so their expected host does not depend on InetUtils selecting the same local interface.Closes #1323.