Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log warning on slow host resolution #7087

mbhave opened this issue Oct 3, 2016 · 29 comments

Log warning on slow host resolution #7087

mbhave opened this issue Oct 3, 2016 · 29 comments


Copy link

@mbhave mbhave commented Oct 3, 2016

The current logger startup can be quite slow on a fresh OSX install. The root cause is:

InetAddress.getLocalHost().getHostName() in StartupInfoLogger

See for workaround and background

Copy link

@wilkinsona wilkinsona commented Oct 5, 2016

I don't think we should be trying to work around this. The underlying cause has been in Java for some time. I believe it's appearing more frequently now due to the (mis)configuration of macOS after an upgrade to Sierra. It's also happened in the past with other macOS upgrades.

When you request a hostname, the JDK resolves it to IP addresses. It then tries a reverse lookup of those addresses and checks that at least one of the results maps back to the input host name. It's this reverse lookup that's slow. The slowness isn't limited to the JVM. Anything on the OS that tries to perform such a reverse lookup will be slow without appropriate configuration in /etc/hosts.

Copy link

@snicoll snicoll commented Oct 5, 2016

For the record, I was about to write something similar this morning and forgot. I don't think we should try to find a workaround in our codebase for this.

Copy link

@philwebb philwebb commented Oct 6, 2016

I was hoping there would be a system property that we could use, but I can't find one. I can't get the lookup to slow down locally, but I wondered if this would be an option:

        long time = System.nanoTime();
        if (true) {
            Class<?> inetAddress = InetAddress.class;
            Field field = ReflectionUtils.findField(inetAddress, "impl");
            Object impl = ReflectionUtils.getField(field, null);
            Method method = ReflectionUtils.findMethod(impl.getClass(),
            System.out.println(ReflectionUtils.invokeMethod(method, impl));
        else {
        System.out.println(TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - time));

It's probably too hacky!

Copy link

@philwebb philwebb commented Oct 6, 2016

Another option might be to call InetAddress.getLocalHost().getHostName() in a thread with and timeout if we don't get an answer quickly.

Copy link

@spencergibb spencergibb commented Oct 6, 2016

@philwebb we use another thread in InetUtils in spring cloud.

Copy link

@wilkinsona wilkinsona commented Oct 6, 2016

They're all point solutions for a JVM- or even OS- wide problem. People will almost inevitably hit another call to getHostname() that's slow and fix their network configuration. At that point we're needlessly using a reflective hack or spawning a thread. I really don't think we should.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.


This comment was marked as off-topic.

Copy link

@wilkinsona wilkinsona commented Jan 17, 2019

This came up again recently:

I'm still not in favour of trying to work around the problem as it will almost certainly occur elsewhere in the app in a place that's out of our control. Perhaps, in a place that is in our control, we could log a warning when the resolution is too slow:

diff --git a/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/ b/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/
index a8b69cb091..82dcc3293b 100644
--- a/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/
+++ b/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/
@@ -47,7 +47,7 @@ class StartupInfoLogger {
        public void logStarting(Log log) {
                Assert.notNull(log, "Log must not be null");
                if (log.isInfoEnabled()) {
-             ;
+             ;
                if (log.isDebugEnabled()) {
@@ -60,12 +60,12 @@ class StartupInfoLogger {
-       private String getStartupMessage() {
+       private String getStartupMessage(Log log) {
                StringBuilder message = new StringBuilder();
                message.append("Starting ");
-               message.append(getOn());
+               message.append(getOn(log));
                return message.toString();
@@ -105,8 +105,17 @@ class StartupInfoLogger {
                return getValue(" v", () -> source.getPackage().getImplementationVersion(), "");
-       private String getOn() {
-               return getValue(" on ", () -> InetAddress.getLocalHost().getHostName());
+       private String getOn(Log log) {
+               return getValue(" on ", () -> {
+                       InetAddress localHost = InetAddress.getLocalHost();
+                       long start = System.currentTimeMillis();
+                       String hostName = localHost.getHostName();
+                       if (System.currentTimeMillis() - start > 200) {
+                               log.warn("Resolution of the local host's name took in excess of 200ms."
+                                               + " Please verify your network configuration");
+                       }
+                       return hostName;
+               });

200ms is a rather arbitrary value. Resolution takes 0.2ms on my machine so hopefully 1000x that should be sufficient to avoid false positives.

Copy link

@MichelSchudel MichelSchudel commented Jan 18, 2019

The call to iNetAdress only occurs once, as far as I can see, per spring boot web app. Yet I see some remarks on twitter of it being called multiple times. Does anyone have a sample where the problem occurs?

Copy link

@sdeleuze sdeleuze commented Jan 18, 2019

While I agree that printing the hostname is useful and should not be removed, I think it can be slow in various use cases, especially since JDK is using a more reliable and also potentially slower mechanism. Having Spring Boot startup time depending on that seems fragile to me.

I would vote for @philwebb proposal:

Another option might be to call InetAddress.getLocalHost().getHostName() in a thread with and timeout if we don't get an answer quickly.

Creating a dedicated thread for that is likely "too much", but what about using the one created in BackgroundPreinitializer to trigger StartupInfoLogger?

Copy link

@MichelSchudel MichelSchudel commented Jan 18, 2019

Again, are there cases where INetAddress is called multiple times? Reducing the number of calls is much simpler than trying to further eliminate the issue by using threading or something similair...

Copy link

@wilkinsona wilkinsona commented Jan 18, 2019

The conclusion in the JDK issue is that "the times in the report are likely a local configuration issue". That matches what we have seen too. Using a separate thread and timing out is going to add overhead that slows things down for everyone just to benefit the few that have a local configuration issue. I don't think it makes sense to do that. We've discussed this problem this week and the Boot team are in agreement that we should time how long the call takes and log when it takes too long. The timing will still introduce overhead, but it's tiny in comparison to using a separate thread.

Copy link

@wilkinsona wilkinsona commented Jan 18, 2019

Again, are there cases where INetAddress is called multiple times?

It's not really possible to answer that. What happens in Boot's own code is only part of the picture. As noted above, Tomcat will also make a similar call for example. To see the full picture you'd need to know about all of the code in the app.

Copy link

@MichelSchudel MichelSchudel commented Jan 18, 2019

That's true, but for SpringBoot itself we could at least do something like this:

public final class HostNameResolver {

    private static final String UNRESOLVED_HOST_NAME = "unknown";

    private static String hostname = UNRESOLVED_HOST_NAME;
     * Tries to resolve a hostname. If it's not resolved within the specified timeout, a "unknown" string will be returned.
     * The lookup process will still continue asynchronously, so the next call to this method might return the hostname.
     * @param timeoutInMillis the max time to wait for a hostname
     * @return the hostname, or "unknown" if it has not been resolved yet.
    public static String getHostname(int timeoutInMillis) {
        if (UNRESOLVED_HOST_NAME.equals(hostname)) {
            ExecutorService executorService = Executors.newSingleThreadExecutor();
            Future future = executorService.submit(()-> {hostname = InetAddress.getLocalHost().getHostName(); return hostname;});
            try {
                return (String) future.get(timeoutInMillis, TimeUnit.MILLISECONDS);
            } catch (TimeoutException e) {
                //do nothing
            } catch (InterruptedException | ExecutionException e) {
                throw new RuntimeException(e);
        return hostname;

The call to InetAdress.getLocalHost().getHostName() can then be replaced with HostNameResolver.getHostName(..) with a sensible default timeout (for example, 500ms). Subsequent calls will eventually return the host name.

Copy link

@wilkinsona wilkinsona commented Jan 18, 2019

Spring Boot itself only resolves the host name once. Thanks for the suggestion, but as I've already explained above, using a thread and timing out adds overhead that's larger than we want for a problem that only affects those with a network configuration problem.

@wilkinsona wilkinsona changed the title Find alternative for InetAddress.getLocalHost().getHostName() Warn when InetAddress.getLocalHost().getHostName() takes longer than expected Jan 18, 2019
@wilkinsona wilkinsona added this to the 2.2.x milestone Jan 18, 2019
Copy link

@philwebb philwebb commented Jan 18, 2019

FWIW I've also changed my mind about using a thread since I wrote #7087 (comment). The timeout warning seems like the best option to me because it will tell users that they have a problem and allow them to fix it for every getHostName call (not just the one that Boot makes).

@spring-projects spring-projects locked as too heated and limited conversation to collaborators Jan 18, 2019
@spring-projects spring-projects unlocked this conversation Feb 18, 2019
Copy link

@sdeleuze sdeleuze commented Feb 18, 2019

After another look on that issue, please find bellow my updated thoughts:

  • I agree that using a dedicated thread is not a solution
  • With Spring Boot 2.1.3 using only the web starter, the first invocation of InetAdress.getLocalHost().getHostName() I see is from ApplicationPid#getPid (notice that the hostname is not kept) invoked by LoggingSystemProperties, only the second invocation (where the hostname is really needed) and the third (ApplicationPid#getPid again) are from StartupInfoLogger
  •​() can be used on Java 9+ to get the PID without trigerring localhost name resolution
  • I don't see invocation of InetAdress.getLocalHost().getHostName() by Tomcat, maybe we could reach them to see if they avoided such call which is now potentially slow depending on the environment?
  • Is the MacOS misconfiguration only occurring for people upgrading or is it impacting every install form scratch?
  • Could we discuss how much this information is useful? I have still big doubts on the value at risk of resolving + printing the hostname at startup. DNS resolution was fast and sometimes not accurate before Java 1.8.0_60, and is since potentially slow and more accurate. If the fact that Tomcat is not using InetAdress.getLocalHost().getHostName() is confirmed, making Boot depending on the DNS configuration is maybe too fragile. Are we sure this call is fast on every platform? I would not bet on that.

Copy link

@spencergibb spencergibb commented Feb 18, 2019

We timeout in spring cloud

Copy link

@wilkinsona wilkinsona commented Feb 18, 2019

  •​() can be used on Java 9+ to get the PID without trigerring localhost name resolution

We can consider that, but it has a cost of its own. We compile against Java 8 at the moment. The idea of going back to compiling against a newer version of Java and requiring Animal Sniffer to catch accidental usage of new APIs is rather off-putting. And it's still a point solution for a broader problem. See below.

  • I don't see invocation of InetAdress.getLocalHost().getHostName()

Tomcat calls getHostName() which may trigger DNS resolution in a few places. Here is one. Undertow, Reactor Netty, Netty, and Jetty all make similar calls. If you’re using a host with misconfigured DNS where a look up is slow, it's very likely that you'll be affected no matter what we do in Boot.

  • Is the MacOS misconfiguration only occurring for people upgrading or is it impacting every install form scratch?

I don't think we know for sure. Anecdotally, I don't recall my new MacBook being affected.

Copy link

@haskovec haskovec commented Feb 18, 2019

When I saw the issue in 2016, I had upgraded my MacBook to Sierra I think. My new MacBook Pro running Mojave hasn't seen the issue.

@philwebb philwebb self-assigned this Apr 19, 2019
@philwebb philwebb changed the title Warn when InetAddress.getLocalHost().getHostName() takes longer than expected Log warning on slow host resolution Apr 19, 2019
@philwebb philwebb removed this from the 2.2.x milestone Apr 19, 2019
@philwebb philwebb added this to the 2.2.0.M3 milestone Apr 19, 2019
@philwebb philwebb closed this in 1f893d9 Apr 19, 2019
coatsr added a commit to coatsr/spring-boot that referenced this issue Apr 24, 2019
* Check for Reactor Netty disconnected client errors

Closes spring-projectsgh-16046

* Upgrade to Spring Batch 4.0.3

Closes spring-projectsgh-16422

* Upgrade to Spring Batch 4.1.2

Closes spring-projectsgh-16423

* Avoid bean method proxying in WebMVC and WebFlux config

This commit applies changes similar to what's been done in spring-projectsgh-9068, for
MVC and WebFlux configurations. This is now possible thanks to the
changes done in Spring Framework in

Fixes spring-projectsgh-16427

* Next Development Version

* Upgrade to Solr 6.6.6

Closes spring-projectsgh-16428

* Upgrade to Netty Tcnative 2.0.24.Final

Closes spring-projectsgh-16429

* Fixup version numbers following release

* Polish

* Upgrade to Micrometer 1.1.4

Close spring-projectsgh-16425

* Align with new fail-fast behaviour in Micrometer 1.1.4

Closes spring-projectsgh-16425

* Upgrade to Classmate 1.5.0

Closes spring-projectsgh-16430

* Upgrade to Thymeleaf Layout Dialect 2.4.1

Closes spring-projectsgh-16431

* Upgrade to Artemis 2.7.0

Closes spring-projectsgh-16432

* Upgrade to Assertj 3.12.2

Closes spring-projectsgh-16434

* Upgrade to Elasticsearch 6.6.2

Closes spring-projectsgh-16435

* Upgrade to Hibernate 5.4.2.Final

Closes spring-projectsgh-16436

* Upgrade to Junit Jupiter 5.4.1

Closes spring-projectsgh-16437

* Upgrade to Mariadb 2.4.1

Closes spring-projectsgh-16438

* Upgrade to Mockito 2.25.1

Closes spring-projectsgh-16439

* Upgrade to Sqlite Jdbc 3.27.2

Closes spring-projectsgh-16440

* Upgrade to Spring Session Bean-SR4

See spring-projectsgh-16357

* Upgrade to Spring Integration 5.1.4

See spring-projectsgh-16350

* Prohibit upgrades to Derby 10.15 as it requires Java 9

See spring-projectsgh-16433

* Next development version (v2.0.10.BUILD-SNAPSHOT)

* Polish

* Update copyright header of changed files

* Increase timeout for promote script

Increase the timeout used when checking if artifacts have landed in
Bintray from 20m to 40m. Also added some additional protection against
the curl command failing.

Closes spring-projectsgh-16443

* Update copyright header of changed files

* Fix checkstyle violation

* Next development version (v2.1.5.BUILD-SNAPSHOT)

* Fixup promote script

* Allow promote script to be run again

* Reinstate SNAPSHOT updates in integration tests

Fixes spring-projectsgh-16453

* Polish

* Polish

* Let Hibernate detect the dialect to use

Closes spring-projectsgh-16172

* Add forward merge issue creation hook

Closes spring-projectsgh-16458

* Honor custom change log tables in Liquibase endpoint

Closes spring-projectsgh-16442

* Avoid infinite cycle resolving generic type that refers itself

This commit improves type resolution for a unresolved generic type that
uses itself in its upper bound declaration.

Closes spring-projectsgh-16451

* Output information about issue created for forward merge

See spring-projectsgh-16458

* Simplify the configuration of the ProtocolHandler

This commit introduces a new callback interface that can
be used to customize the ProtocolHandler on a Tomcat Connector.

See spring-projectsgh-16342

* Polish "Simplify the configuration of the ProtocolHandler"

Closes spring-projectsgh-16342

* Polish embedded tomcat setup

See spring-projectsgh-16446

* Polish "Polish embedded tomcat setup"

Closes spring-projectsgh-16446

* Migrate ApplicationContext to common hierarchy

This commit migrates `AnnotationConfigReactiveWebApplicationContext`
parent to the `GenericApplicationContext` abstraction. Any use of
`AnnotationConfigWebApplicationContext` is also removed as it also
inherits from the `AbstractRefreshableApplicationContext` outdated

A new `AnnotationConfigServletWebApplicationContext` context is
introduced instead, extending from `GenericApplicationContext` and
providing the counter part of the reactive context for the Servlet-based
web app tests.

See spring-projectsgh-16096

* Polish "Migrate ApplicationContext to common hierarchy"

Users calling the methods will still face problems but at least they
will have some guidance.

Closes spring-projectsgh-16096

* Only start management server once main server is initialized

Closes spring-projectsgh-15378

* Skip lazy init for beans that explicitly set lazy to false

This commit also adds tests to ensure that the child
management context works when lazy initialization is
enabled. Also, it adds a BeanFactoryPostProcessor to
the child context so that the server is created and
listening for requests but other beans in the child
context are not created until requested.

See spring-projectsgh-16184

* Update devtools to use @lazy(false)

Fixes spring-projectsgh-16184

* Fix compilation error

Closes spring-projectsgh-16476

* Fix build failure

* Fix Thymeleaf deprecations

Closes spring-projectsgh-16478

* Add reference to

* Add missing backquote

See spring-projectsgh-16483

* Polish "Add missing backquote"

Closes spring-projectsgh-16483

* Add support for public key file for OAuth2 resource server

Closes spring-projectsgh-15814

* Allow `ApplicationContextRunner` to accept simple bean definitions

This commit adds `withBean` methods to the `ApplicationContextRunner`
abstraction so that simple beans can be registered inline. This is a
nice alternative for cases where a inner configuration class has to be
defined for the purpose of creating a simple bean.

Closes spring-projectsgh-16011

* Migrate tests to use withBean

See spring-projectsgh-16011

* Polish

* Polish

See spring-projectsgh-15814

* Polish

Closes spring-projectsgh-16494

* Overriding getMappingPathPatterns is not required

After a hierarchy change in Spring Framework in spring-projectsgh-22543,
`AbstractWebFluxEndpointHandlerMapping` doesn't need to override the
`getMappingPathPatterns` method anymore.

* Upgrade to Spring Framework 5.2.0.M1

Fixes spring-projectsgh-16173

* Upgrade to Rabbit Amqp Client 5.7.0

Closes spring-projectsgh-16518

* Upgrade to Junit Jupiter 5.4.2

Closes spring-projectsgh-16519

* Upgrade to Mongodb 3.10.2

Closes spring-projectsgh-16520

* Upgrade to Neo4j Ogm 3.2.0-alpha05

Closes spring-projectsgh-16521

* Upgrade to Hazelcast 3.12

Closes spring-projectsgh-16503

* Upgrade to Undertow 2.0.20.Final

Closes spring-projectsgh-16522

* Upgrade to Aspectj 1.9.3

Closes spring-projectsgh-16523

* Upgrade to Infinispan 9.4.12.Final

Closes spring-projectsgh-16524

* Upgrade to Jooq 3.11.11

Closes spring-projectsgh-16525

* Fix package of java.time.Duration in documentation

Closes spring-projectsgh-16527

* Upgrade to Spring Data Moore M3

Closes spring-projectsgh-16528

* Fix unresolved directives in generated documentation

Closes spring-projectsgh-16452

* Add RSocket server support with Spring Messaging

This commit adds support for RSocket server applications.
The auto-configuration will either add RSocket support to an existing
Reactor Netty server in a WebFlux application (as a WebSocket endpoint),
or bootstrap a brand new RSocket server instance.

Spring Boot will also auto-configure the Spring Messaging infrastructure
that supports Controller beans with `@MessageMapping` annotated methods.

Fixes spring-projectsgh-16021

* Add requestId info to ErrorAttributes in WebFlux

See spring-projectsgh-15952

* Polish

Closes spring-projectsgh-15952

* Polish RSocket server support

Relax the `NettyRSocketBootstrap` contract to allow all types of
`SocketAcceptor` implementations.

See spring-projectsgh-16021

* Fix Javadoc build for new RSocket dependencies

See spring-projectsgh-16021

* Upgrade to Spring Kafka 2.3.0.M1

Closes spring-projectsgh-16302

* Provide an option to use Spring's forwarded header support

Previously, if the `server.use-forward-headers` property
was set to true, X-Forwarded-* headers support was provided
at the server level. The property has been deprecated in favor
of `server.forward-headers-strategy` which can be also be configured
to use Spring's forwarded header support apart from native server support.

Closes spring-projectsgh-5677

* Forwarded header auto-config should be conditional on missing bean

See spring-projectsgh-5677

* Fix javadoc

* Fix build following Spring Security changes

* Fix javadoc

* Upgrade to Kotlin 1.3.30

Closes spring-projectsgh-16554

* Upgrade to Spring AMQP 2.2.0.M1

Closes spring-projectsgh-16530

* Switch to snapshots in preparation for the release

* Remove outdated exclusion to http-client

Closes spring-projectsgh-16510

* Deprecate Elasticsearch transport and Jest clients

As of Spring Data Moore, the Elasticsearch high level REST client is
supported for Spring Data repositories. The transport client is now
deprecated and is likely to be removed in a future Spring Data release.

This commit deprecates the transport client and marks all the associated
configuration properties as deprecated. The Spring Boot starter depends
on the `spring-data-elasticsearch` project, which now depends on both
transport client and high level REST client.

This commit also deprecates the Jest client, as Spring Boot will focus
on supporting the high level REST client and the reactive client
provided by Spring Data - both being in sync with the fast release pace
of Elasticsearch.

Closes spring-projectsgh-15008

* Adapt Gradle plugin tests to change in Kotlin's packaging

Closes spring-projectsgh-16554

* Restore indentation in published spring-boot-dependencies pom

The move to an HTTPS URL for the xmlns:xslt identifier has the unwanted
side-effect of disabling indentation.

This commit moves back to an HTTPS URL. It also changes the indent size
to 2, aligning with the size used by all the other poms that are written
by the flatten plugin.

Closes spring-projectsgh-16466

* Fix source detection in case of multiple candidates

This commit improves the detection of a property source when more than
one group with the same type exist.

Closes spring-projectsgh-16549

* Upgrade to asciidoctor-maven-plugin 1.6.0

* Upgrade to Spring Session Corn-M1

Closes spring-projectsgh-16532

* Make it easier to identify issues created for forward ports

Closes spring-projectsgh-16566

* Upgrade to Spring Security 5.2.0.M2

Closes spring-projectsgh-16534

* Polish RSocket server bootstrap

See spring-projectsgh-16021

* Fix imports ordering

* Revert "Upgrade to asciidoctor-maven-plugin 1.6.0"

This commit introduced an incompatible change in the asciidoct
API: both asciidoctorj-pdf and spring-asciidoctor-extensions
expect `org.asciidoctor.extension.JavaExtensionRegistry` to be
a class, not an interface.

This reverts commit 120ffb1.

* Upgrade to Elasticsearch 6.7.1

Closes spring-projectsgh-16569

* Upgrade to Spring Integration 5.2.0.M1

Closes spring-projectsgh-16531

* Upgrade to Spring Batch 4.2.0.M1

Closes spring-projectsgh-16529

* Deprecate ElasticsearchHealthIndicator

Since the transport client has been deprecated in spring-projectsgh-15008, the health
indicator for that should be deprecated as well.

See spring-projectsgh-15008

* Make nested classes in JsonTestersAutoConfiguration package private

Closes spring-projectsgh-15444

* Add tests for CompressionConnectorCustomizer

Closes spring-projectsgh-16515

* Add property to configure Mongo auto index creation

Closes spring-projectsgh-16454

* Polish "Add property for mongo auto-index creation"

See spring-projectsgh-16454

* Polish

* Polish

* Align withBean methods with ApplicationContext

Rework `AbstractApplicationContextRunner.withBean` methods to
align signatures as much as possible with those provided by
the `ApplicationContext`.

Also update the implementation to use a dedicate member
variable rather than adding initializers.

Closes spring-projectsgh-16011

* Update copyright header of changed files

* Revert accidental TomcatSample changes

* Remove dependency management for solr-uima following upgrade to 7.7.1

Closes spring-projectsgh-16490

* Tolerate competing gRPC version requirements in Micrometer's registries

See spring-projectsgh-16178

* Ignore non-existent Spring Data MongoDB module

Closes spring-projectsgh-16573

* Add missing RSocket dependency management

Closes spring-projectsgh-16568

* Restore indentation in published spring-boot-starter-parent pom

Closes spring-projectsgh-16466

* Update docs to reflect rename of @ConfigurationPropertiesDefaultValue

See spring-projectsgh-8762

* Fix syntax highlighting in the reference documentation

Closes spring-projectsgh-16548

* Disable DevTools' post-processors and auto-config when running tests

Closes spring-projectsgh-5307

* Use BatchErrorHandler when Kafka listener type is batch

Closes spring-projectsgh-16499

* Test the Gradle plugin against Gradle 5.4

Closes spring-projectsgh-16576

* Polish "Use BatchErrorHandler when Kafka listener type is batch"

Closes spring-projectsgh-16499

* Polish

See spring-projectsgh-16575

* Polish

Closes spring-projectsgh-16575

* Upgrade to Tomcat 9.0.19

Closes spring-projectsgh-16591

* Upgrade to Tomcat 9.0.19

Closes spring-projectsgh-16591

* Support configuration of Flyway's Pro properties

Closes spring-projectsgh-14989

* Allow Flyway tests to import internal exception

Closes spring-projectsgh-14989

* Complete Jetty Access Log configuration properties support

See spring-projectsgh-16080

* Polish "Complete Jetty Access Log configuration properties support"

Closes spring-projectsgh-16080

* Add auto-configuration support for ReactiveGridFsTemplate

See spring-projectsgh-16467

* Polish "Add auto-configuration support for ReactiveGridFsTemplate"

Closes spring-projectsgh-16467

* Make EL available to reactive web apps as it already is to servlet web apps

Closes spring-projectsgh-16596

* Allow to configure the Elasticsearch rest client timeouts

See spring-projectsgh-15965

* Polish "Allow to configure the Elasticsearch rest client timeouts"

Closes spring-projectsgh-15965

* Update WebFlux starter to depend on validation starter

Previously, the WebFlux starter declared direct dependencies on Hibernate Validator
and the Jakarta EE validation API. This meant that it required two exclusions to
exclude validation from a reactive web application that did not need it.

This commit updates the WebFlux starter to get its validation dependencies via a
dependency on the validation starter. This allows validation to be excluded
using a single exclusion. The EL dependency from the validation starter has
been excluded to allow the EL implementation from the underlying container
starter to continue to be used instead.

See spring-projectsgh-16593

* Add support for configuring remaining Undertow server options

This commit adds support for configuring Undertow's server options that were previously
not configurable via application properties. The additions are the following:

- allow-encoded-slash
- always-set-keep-alive
- decode-url
- max-cookies
- max-headers
- max-parameters,
- url-charset

See spring-projectsgh-16278

* Polish "Add support for configuring remaining Undertow server options"

See spring-projectsgh-16278

* Determine Spring Boot version correctly when using module path

In Java 9, a package may return null for its implementation version
even when the manifest attribute specifying the version is present
in the jar from which the package was loaded.

This commit updates SpringBootVersion to fall back to
accessing the jar and its manifest attributes directly when the
implementation version of its package is null.

See spring-projectsgh-16182

* Polish "Determine Spring Boot version correctly when using module path"

See spring-projectsgh-16182

* Analyze failure if configprop scanning results in two beans

Closes spring-projectsgh-16581

* Add dependency management for okhttp3

Closes spring-projectsgh-6385

* Migrate to MergedAnnotations API

Migrate away from `AnnotationUtils` and `AnnotatedElementUtils`
when possible to the new `MergedAnnotations` API.

Closes spring-projectsgh-16551

* Polish

Closes spring-projectsgh-16597

* Improve DefaultCookieSerializer auto-configuration

Spring Session's own configuration support (i.e.
SpringHttpSessionConfiguration) will configure the default
DefaultCookieSerializer with rememberMeRequestAttribute if
SpringSessionRememberMeServices bean has been detected in the
application context.

In contrast, Spring Boot's auto-configured DefaultCookieSerializer does
not do this which results in a different out-of-the-box experience for
users that rely on Spring Session's remember-me integration.

This commit improves Spring Session DefaultCookieSerializer
auto-configuration to match Spring Session's behavior and make the
auto-configured DefaultCookieSerializer aware of
SpringSessionRememberMeServices bean.

See spring-projectsgh-16513

* Polish "Improve DefaultCookieSerializer auto-configuration"

Closes spring-projectsgh-16513

* Cache MimeTypes to improve performance

See spring-projectsgh-16507

* Polish "Cache MimeTypes to improve performance"

Closes spring-projectsgh-16507

* Fix failure analyzer message

See spring-projectsgh-16581

* Polish StartupInfoLogger message creation

Rework some of the internals of `StartupInfoLogger` so that fewer
strings are created.

* Log warning on slow host resolution

Update `StartupInfoLogger` so that if the `InetAddress` call takes
more than 200ms a warning is logged.

Closes spring-projectsgh-7087

* Fix checkstyle violation

Closes spring-projectsgh-16616

* Fix UndertowWebServer's logger name

See spring-projectsgh-16613

* Polish "Fix UndertowWebServer's logger name"

Closes spring-projectsgh-16613

* Apply server customizer beans automatically

See spring-projectsgh-16584

* Polish "Apply server customizer beans automatically"

Closes spring-projectsgh-16584

* ConfigurationPropertiesScan should account for conditions

Fixes spring-projectsgh-16612

* Fix tests

* Add missing GlassFish JAXB dependency management

Closes spring-projectsgh-16619

* Use MIME decoder to read OAuth2 resource server public key

Fixes spring-projectsgh-16624

* Use latest Docker Java and a compatible version of Jersey

Closes spring-projectsgh-16625

* Optimize JarEntry construction

This commit avoids calling the underlying ZipEntry.setExtra() method
that is not very inline friendly in cases where there is no extra
information to be set.

See spring-projectsgh-16620

* Add resource icons to CI pipeline

* Use AdoptOpenJDK for Ubuntu launch script integration tests

Closes spring-projectsgh-16633

* Polish Maven Plugin's tests

See spring-projectsgh-16618

* Polish "Polish Maven Plugin's tests"

See spring-projectsgh-16618
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants