Open
Description
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.