TL;DR

When using an internal WebJars package and switching to the new webjars-locator-lite-Locator make sure a file META-INF/resources/webjars-locator.properties with web-jar-name.version=x.y.z exists in your classpath. Favourable, this file is already shipped within your WebJars package.

The long story

When upgrading to Spring Boot 3.4.0 the upgrading section within the release notes mentions that you should switch to the new webjars-locator-lite dependency if you are using WebJars:

For faster startup times and efficient WebJars asset resolution, you will need to update your pom.xml/build.gradle to depend on org.webjars:webjars-locator-lite instead of org.webjars:webjars-locator-core (both dependencies are managed by Spring Boot). Note that org.webjars:webjars-locator-core support in Spring is now deprecated and will be removed in a future version. See the reference documentation section on this feature.

Because we are using an internal WebJar for styling one of our applications, I followed that guide and changed the dependency within my pom.xml. But after starting the application locally, no styles were applied and the previous working WebJars path only responded with 404 Not Found responses.

As I couldn’t find any documentation, I started debugging and quickly found out that the new locator by default only works when the included WebJars live within an artifact groupId of org.webjars.npm or org.webjars.

Of course, that was not the case for our internal WebJars package and therefore didn’t work. But luckily, I found out that there is a configuration option that can be used to fix that. On startup, the used WebJarVersionLocator tries to read a file META-INF/resources/webjars-locator.properties from the classpath. If this file is present and contains an entry of type web-jar-name.version=x.y.z everything is working again and the content of the WebJar can be loaded.

Placing such a configuration file within your application therefore enables you to switch to the new WebJars locator and benefit from the decreased startup time. But I would consider that just a workaround, and the real solution is to include that configuration file already within your internal WebJars package. This enables the usage of the package without any modification within the application and therefore removes the need to duplicate that within every consumer of your WebJar.

TAGS