Docker container fails to start from version 76.24.0 onwards
kukumber opened this issue · 16 comments
I'm encountering an issue where I can't run the Docker container starting from version 76.24.0.
With version 76.23.0, the container starts without any issues. I've been using the following command:
docker run --rm \
--env CATALINA_OPTS="-Djava.security.egd=file:/dev/./urandom -Dlog4j.configurationFile=/var/uaa/log4j.properties" \
--env UAA_CONFIG_PATH="/var/uaa/" \
--mount type=bind,src=./log4j.properties,dst=/var/uaa/log4j.properties \
--mount type=bind,src=./uaa.yml,dst=/var/uaa/uaa.yml \
cloudfoundry/uaa:76.23.0
However, starting from version 76.24.0, the container crashes with the following error:
[CONTAINER] lina.core.ContainerBase.[Catalina].[localhost].[/] SEVERE Exception starting filter [rateLimitingFilter]
java.lang.UnsupportedClassVersionError: org/cloudfoundry/identity/uaa/ratelimiting/RateLimitingFilter has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 (unable to load class [org.cloudfoundry.identity.uaa.ratelimiting.RateLimitingFilter])
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2341)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:810)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1293)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1141)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:488)
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:470)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:142)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:242)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:97)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4311)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4940)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:683)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:658)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:661)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1184)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1932)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1094)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:476)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1617)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:114)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:345)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:893)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:794)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:866)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:248)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:433)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:921)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:347)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
[CONTAINER] lina.core.ContainerBase.[Catalina].[localhost].[/] SEVERE Exception starting filter [backwardsCompatibleScopeParameter]
java.lang.UnsupportedClassVersionError: org/cloudfoundry/identity/uaa/web/BackwardsCompatibleScopeParsingFilter has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 (unable to load class [org.cloudfoundry.identity.uaa.web.BackwardsCompatibleScopeParsingFilter])
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2341)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:810)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1293)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1141)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:488)
at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:470)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:142)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:242)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:97)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4311)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4940)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:683)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:658)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:661)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1184)
at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1932)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1094)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:476)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1617)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:318)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:114)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:345)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:893)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:794)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:866)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:248)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:433)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:921)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:171)
at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:347)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
[CONTAINER] org.apache.catalina.core.StandardContext SEVERE One or more Filters failed to start. Full details will be found in the appropriate container log file
[CONTAINER] org.apache.catalina.core.StandardContext SEVERE Context [] startup failed due to previous errors
I've tested all available versions from 76.24.0 to 76.29.0 and encountered the same issue.
Any assistance in resolving this would be greatly appreciated.
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/186740037
The labels on this github issue will be updated when the story is started.
Hi,
I was not aware, that cloudfoundry/uaa is still created in docker hub.
The error reason is the JDK 17 upgrade in uaa.war but obviously not in docker container, e.g. Dockerfile
@Tallicia @peterhaochen47 @hsinn0 Can you please check where the deployment to cloudfoundry/uaa:76.29.0 is located and also update the image file ? similar to https://github.com/pivotal/uaa-ci/commit/e946ae21fb76429b2d663b844df510ce18274882
Thanks
The Dockerfile was deleted in #2422 because this was not used to create images in https://hub.docker.com/r/cloudfoundry/uaa/tags.
Yes, there is a separate process (not Dockerfile based) creating and publishing https://hub.docker.com/r/cloudfoundry/uaa. We will discuss this issue at our next planning meeting.
@kukumber Could you try again with the latest release (76.30.0)?
I think still 11 inside the image
-> docker inspect cloudfoundry/uaa:76.30.0
Find "io.paketo.stacks.tiny","*"],"uri":"https://github.com/bell-sw/Liberica/releases/download/11.0.21+10/bellsoft-jre11.0.21+10-linux-amd64.tar.gz\",\"version\":\"11.0.21\"}}
And tomcat 9.0.83 is inside instead of expected 9.0.85
Looking into it again
@peterhaochen47 I checked with version 76.30.0 just in case. I see the same error.
I've checked the version 76.31.0, the issue still persists.
Just tried cloudfoundry/uaa:77.0.0 and it looks like the issue has been fixed. Could you give it a try?
@peterhaochen47 Yes, I've checked version 77.0.0, the container starts without errors. Thank you.
Hi @kukumber, could we ask about your use case of this docker image? And are you using it as part of some larger product?
Hi @peterhaochen47, unfortunately, I can't disclose details of the services because of an NDA. I can only say that it's part of an internal infrastructure.
Hi @peterhaochen47, unfortunately, I can't disclose details of the services because of an NDA. I can only say that it's part of an internal infrastructure.
I see. We are asking because we plan to soon stop publishing the image; the reason is that there appears to be very limited usage of it & that the hosted service we use to build the image is being sunset as well. If you still need it, you can build the image yourself. We were using kpack to build it (for which we could share the kpack configs); or you could write a tranditional Dockerfile.
I see. We are asking because we plan to soon stop publishing the image; the reason is that there appears to be very limited usage of it & that the hosted service we use to build the image is being sunset as well. If you still need it, you can build the image yourself. We were using kpack to build it (for which we could share the kpack configs); or you could write a tranditional Dockerfile.
Oh, I got it. I would appreciate it if you could share the kpack configs.
Hi all! I would also have interest in the kpack files. :)