[jira] [Comment Edited] (GROOVY-11524) Error with circular loading of installed providers when using transitive dependency groovy 4.0.23 in docker

["Lennard Wolf (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-11524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901530#comment-17901530 ] 

Lennard Wolf edited comment on GROOVY-11524 at 11/27/24 4:17 PM:
-----------------------------------------------------------------

Hi [~daniel_sun] ,
Thank you for the provided snapshot. When I lookup the changes and compare them with our stacktrace, this could be a fix to our issue, at least the error handling seem to ignore errors thrown at the level at which the application currently crashes when using the affected versions.

I invoked your snapshot in my local setup. Unfortunately, I was not able to reproduce the error in my local docker setup when using the affected versions. Only within our cloud environment the error seems to appear. Therefore, I could not determine whether the fix solves the issue when including your snapshot locally. May it be possible to invoke the fix within the upcoming groovy release, that I could test it within our cloud environment?


was (Author: JIRAUSER307858):
Hi [~daniel_sun] ,
I invoked your snapshot in my local setup. Unfortunately, I was not able to reproduce the error in my local docker setup when using the affected versions. Only within our cloud environment the error seems to appear. Therefore, I could not determine whether the fix solves the issue when including your snapshot locally. May it be possible to invoke the fix within the upcoming groovy release, that I could test it within our cloud environment?

> Error with circular loading of installed providers when using transitive dependency groovy 4.0.23 in docker
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-11524
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11524
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.23
>            Reporter: Lennard Wolf
>            Priority: Major
>
> 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. The difference in both versions is the groovy version that is provided as transitive dependency which was migrated from 4.0.22 to 4.0.23. 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 already contacted the Spring Boot support. Due to the workaround (see below), they asked us to place the issue directly at groovy.
> We are using the following versions:
>  * {*}Version of Thymeleaf{*}: spring-boot-starter-thymeleaf:3.3.4 (embedded groovy version 4.0.23)
>  * {*}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:*
> {code:java}
> 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){{}} {code}
> {*}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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)