spring-boot: Missing resource handling configuration when separate management context is configured

If we configure the management.server.port and this one is not equal to server.port via spring.web.resources.chain.strategy.content.* generation of the hash does not work and we do not get the correct hashs on the files. If there are some information about this in docs please hint me to it. Otherwise here are an example how to reproduce it:

Id you start this docker-compose file everything will be configured for you and the hashing of the assets in /css/** e.g. does work. Take a look at http://localhost:8080/login with the developer console in Chrome/Firefox e.g. and see that the style.css e.g. does have a hash and if we add the MANAGEMENT_SERVER_PORT=8081 we do not see the hashes. The common.$hash.css file can be ignored this is not placed in /css/** and will be generated via webpack.

version: '2.4'
services:
  mariadb:
    image: mariadb:10.5
    ports:
      - '3308:3306'
    environment:
      - MYSQL_DATABASE=urlaubsverwaltung
      - MYSQL_USER=urlaubsverwaltung
      - MYSQL_PASSWORD=urlaubsverwaltung
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
  mailhog:
    image: mailhog/mailhog:v1.0.0
    ports:
      - '1025:1025'
      - '8025:8025'
  uv:
    image: synyx/urlaubsverwaltung:latest
    ports:
      - '8080:8080'
    environment:
      - SPRING_MAIL_HOST=mailhog
      - SPRING_MAIL_PORT=1025
      - UV_MAIL_SENDER=test@lala.de
      - UV_MAIL_ADMINISTRATOR=test@lala.de
      - UV_MAIL_APPLICATION-URL=http://localhost:8080
      - SPRING_DATASOURCE_URL=jdbc:mariadb://mariadb:3306/urlaubsverwaltung
      - UV_SECURITY_AUTH=default

But know if I add the management.server.port the hash of /css/** files e.g. is not generated

version: '2.4'
services:
  mariadb:
    image: mariadb:10.5
    ports:
      - '3308:3306'
    environment:
      - MYSQL_DATABASE=urlaubsverwaltung
      - MYSQL_USER=urlaubsverwaltung
      - MYSQL_PASSWORD=urlaubsverwaltung
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
  mailhog:
    image: mailhog/mailhog:v1.0.0
    ports:
      - '1025:1025'
      - '8025:8025'
  uv:
    image: synyx/urlaubsverwaltung:latest
    ports:
      - '8080:8080'
    environment:
      - SPRING_MAIL_HOST=mailhog
      - SPRING_MAIL_PORT=1025
      - UV_MAIL_SENDER=test@lala.de
      - UV_MAIL_ADMINISTRATOR=test@lala.de
      - UV_MAIL_APPLICATION-URL=http://localhost:8080
      - SPRING_DATASOURCE_URL=jdbc:mariadb://mariadb:3306/urlaubsverwaltung
      - UV_SECURITY_AUTH=default
      - MANAGEMENT_SERVER_PORT=8081

The default application properties that we add in the given docker container can be seen here https://github.com/synyx/urlaubsverwaltung/blob/master/src/main/resources/application.properties#L30

Do you have any information for us, if this is a common behaviour and how we can achieve having hashed css files and split the server and management port?

Hint: This is independent from docker. I have the same behaviour via ide, ‘java -jar …’ and so on 😃

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (8 by maintainers)

Commits related to this issue

Downgrade to Spring Boot 2.4.1 see https://github.com/spring-projects/spring-boot/issues/25113 — committed to urlaubsverwaltung/urlaubsverwaltung by derTobsch 3 years ago

Most upvoted comments

While something might have changed in Spring Boot that alters the ordering of those parent/child context events in some way, we’ve found that the main issue here is that the ResourceUrlProvider component should not consider events that are not sent by its own application context.

We’re closing this issue and marking it as superseded by spring-projects/spring-framework#26561 (and spring-projects/spring-framework#26562 for the backport).

This will be fixed in Spring Boot 2.4.4, since it will pick up the upcoming Spring Framework 5.3.5 release.

bclozel on Feb 17, 2021

Thanks for helping out here, this is a hard one to figure out.

To reproduce this issue, we need the following:

A Spring Boot application with actuator and a separate management context
A resource chain configured (here for content-based hashing)
A separate WebMvcConfigurer that adds a new resource handling registration

The sample application is here.

Here’s what’s happening:

the custom resource handling registration is registered
the child application context publishes the refreshed context event
the ResourceUrlProvider auto-detects the resource handlers and registers the location, then locks itself from further modifications. At this point the Spring Boot resource registrations are not registered and are ignored at runtime when resolving URLs for resources.
After that, Spring Boot registers its resource handling configuration; another refreshed event is published but this is too late since ResourceUrlProvider now doesn’t allow further modifications.

The expected order is to switch 4) and 3) so that Spring Boot’s resource handling configuration is detected.

I think this could be related to #24748 (and since this is a forward port, its parent issues). The strange part is that I can reproduce this regression with 2.4.2 and 2.3.8.RELEASE, but not 2.2.13.RELEASE where #24745 was originally applied.

It seems that having a parent/child context setup involves an event being fired before the resource handling configuration is processed in the parent. We’ll need more time to figure out what is the problem exactly - I’ll update my sample application right away.

Thanks!

bclozel on Feb 12, 2021

Hi @bclozel, after a lot of fiddling around in WebMvcAutoConfiguration and ResourceUrlProvider I can confirm that everything works as expected!

Our application is using springfox-boot-starter in version 3.0.0 and it seems that there is an issue running managment server on a different port.

I don’t know why, but in https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/resource/ResourceUrlProvider.java#L140 there are just beans available e.g. resourceHandlerMapping using /swagger-ui/**-pattern instead /**.

I checkt the springfox autoconfiguration. In https://github.com/springfox/springfox/blob/master/springfox-boot-starter/src/main/java/springfox/boot/starter/autoconfigure/SwaggerUiWebMvcConfigurer.java#L20 there is a registration of an additional ResourceHandler. I don’t get it why running the management server on the same port is working and on a different port not.

Big thanks for your support mate!

grafjo on Feb 12, 2021

I don’t understand why spring-boot:run and running as a WAR is different here. My advice would be to run the application both ways with debug enabled and collect and compare auto-configuration reports. Maybe something is being configured in one case and not the other?

bclozel on Feb 11, 2021