Error with circular loading of installed providers when using spring-boot-starter-thymeleaf (version 3.3.4) in docker

[LennardWolf2023]

Hello dear thymeleaf community,

We faced an error when migrating spring-boot-starter-thymeleaf with version 3.3.4, that did not occur in the previous 3.3.3 version. When loading a template that uses the layout decorate functionality, a Circular loading of installed providers detected occurs, when the application runs inside an our docker container.

We are using the following versions:

• Version of Thymeleaf: spring-boot-starter-thymeleaf:3.3.4
• Environment: Spring Boot 3.3.4
• Docker base image: public.ecr.aws/docker/library/amazoncorretto:21-alpine-jdk (we just copy the JAR into the docker container and set an entry point)

The stack trace looks like the following:

Stacktrace:

java.lang.Error: Circular loading of installed providers detected java.base/java.nio.file.spi.FileSystemProvider.installedProviders(FileSystemProvider.java: 198)
java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java: 336)
java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java: 288)
org.codehaus.groovy.vmplugin.v9.ClassFinder.maybeNewFileSystem(ClassFinder.java: 177)
org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java:122)
org.codehaus.groovy.vmplugin.v9.ClassFinder.find(ClassFinder.java: 109)
org.codehaus.groovy.vmplugin.v9.Java9.doFindClasses(Java9.java: 120)
org.codehaus.groovy.vmplugin.v9.Java9.getDefaultImportClasses(Java9.java: 107)
org.codehaus.groovy.control.ResolveVisitor.<clinit>(ResolveVisitor.java: 550)
org.codehaus.groovy.runtime.FormatHelper.<clinit>(FormatHelper.java: 71)
org.codehaus.groovy.runtime.InvokerHelper.matchRegex(InvokerHelper.java: 339)
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.matchRegex(ScriptBytecodeAdapter.java: 895)
nz.net.ultraq.thymeleaf.expressionprocessor.ExpressionProcessor.parseFragmentExpression(ExpressionProcessor.groovy: 73)
org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java: 321)
nz.net.ultraq.thymeleaf.layoutdialect.decorators.DecorateProcessor.doProcess(DecorateProcessor.groovy:115)
org.thymeleaf.processor.element.AbstractAttributeModelProcessor.doProcess(AbstractAttributeModelProcessor.java: 77)
org.thymeleaf.processor.element.AbstractElementModelProcessor.process(AbstractElementModelProcessor.java: 98)
org.thymeleaf.util.ProcessorConfigurationUtils$ElementModelProcessorWrapper.process(ProcessorConfigurationUtils.java: 649)
org.thymeleaf.engine.ProcessorTemplateHandler.handleOpenElement(ProcessorTemplateHandler.java: 1510)
org.thymeleaf.engine.OpenElementTag.beHandled(OpenElementTag.java: 205)
org.thymeleaf.engine.Model.process(Model.java: 282)
org.thymeleaf.engine.Model.process(Model.java: 290)
org.thymeleaf.engine.GatheringModelProcessable.process(GatheringModelProcessable.java: 78)
org.thymeleaf.engine.ProcessorTemplateHandler.handleCloseElement(ProcessorTemplateHandler.java: 1640)
org.thymeleaf.engine.CloseElementTag.beHandled(CloseElementTag.java:139)
org.thymeleaf.engine.TemplateModel.process(TemplateModel.java: 136)
org.thymeleaf.engine.TemplateManager.parseAndProcess(TemplateManager.java: 661)
org.thymeleaf.TemplateEngine.process(TemplateEngine.java: 1103)
org.thymeleaf.TemplateEngine.process(TemplateEngine.java: 1064)
org.thymeleaf.TemplateEngine.process(TemplateEngine.java: 1053)
de.otto.core.WarmupService.warmupDetailsTemplate(WarmupService.kt: 266)
de.otto.core.WarmupService.warmupTemplates(WarmupService.kt: 68)
de.otto.core.WarmupService.warmup(WarmupService.kt: 62)
de.otto.core.WarmupService.warmup$default(WarmupService.kt: 60)
de.otto.core.WarmupService.run(WarmupService.kt:360)
org.springframework.boot.SpringApplication.lambda$callRunner$4(SpringApplication.java: 786)
org.springframework.util.function.ThrowingConsumer$1.acceptWithException(ThrowingConsumer.java: 83)
org.springframework.util.function.ThrowingConsumer.accept(ThrowingConsumer.java: 60)
org.springframework.util.function.ThrowingConsumer$1.accept(ThrowingConsumer.java: 88)
org.springframework.boot.SpringApplication.callRunner(SpringApplication.java: 798)
org.springframework.boot.SpringApplication.callRunner(SpringApplication.java: 786)
org.springframework.boot.SpringApplication.lambda$callRunners$3(SpringApplication.java: 774)
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java: 184)
java.base/java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java: 357)
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510)
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java: 499)
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java: 151)
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java: 174)
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java: 234)
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java: 596)
org.springframework.boot.SpringApplication.callRunners(SpringApplication.java: 774)
org.springframework.boot.SpringApplication.run(SpringApplication.java: 342)
org.springframework.boot.SpringApplication.run(SpringApplication.java: 1363)
org.springframework.boot.SpringApplication.run(SpringApplication.java: 1352)
de.otto.ApplicationKt.main(Application.kt:36)

Reproduce:

• Create a Kotlin application with a warm up service that loads the templates initially when starting the application:

@Service
class WarmupService(
val templateEngine: SpringWebFluxTemplateEngine,
) : ApplicationRunner {
// Warmup template 
 fun warmup() {
     repeat(10) {
         templateEngine.process("sampleTemplate", Context(Locale.GERMAN, model))
     }
 }

 override fun run(args: ApplicationArguments) {
   warmup()
 }
}

• load a template (sampleTemplate) with xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout" and layout:decorate="~{layouts/sampleFullBleed}"

The sampleFullBleed looks like the following:

<!DOCTYPE html>
<html
xmlns:th="http://www.thymeleaf.org"
xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"
>
<head>
<title layout:title-pattern="$CONTENT_TITLE">Sample title</title>
</head>
<body>
Some content here
</body>
</html>

• The error occurs when starting the application running in the docker based on alpine

Workaround:
We have found that when we are pinning the groovy version that is delivered within the thymeleaf library to version 4.0.22 instead of using version 4.0.23 that was delivered with the new 3.3.4 version of thymeleaf spring boot starter, the error does not occur anymore. That works for the moment, of course for further releases this could raise other isssues.

We would be very thankful, if you could help us to fix the issue.

[LennardWolf2023]

Hello dear Thymleaf repo maintainers,
I wanted to ask whether there was already someone that took a look at the issue?
Thank you very much in advance.

[LennardWolf2023]

We also placed this report in spring-projects/spring-boot#43207

[danielfernandez]

This is not a Thymeleaf or thymeleaf-spring bug, but instead it seems to be related to the nz.net.ultraq.thymeleaf.layoutdialect (the thymeleaf-layout-dialect project — which is not an official part of the Thymeleaf project.

The layout:decorate / xmlns:layout functionality is provided by that third-party dialect, which uses Groovy internally. The "Circular loading of installed providers" detected error is triggered by Groovy's ClassFinder scanning the filesystem during class resolution. This may have been due to a mismatch in the version of Groovy being used by Spring Boot.