BUG | Tomcat can't redeploy / restart / paralleldeploy a webapp with exousia

[pizzi80]

1. deploy a minimal war of a webapp with weld, soteria and exousia
2. make a "touch" to the war and tomcat try to reload
3. tomcat fails to restart the app

SEVERE [org.apache.catalina.core.StandardContext filterStart] Exception starting filter [org.glassfish.exousia.spi.tomcat.TomcatAuthorizationFilter]
java.lang.NullPointerException: Cannot invoke "Object.hashCode()" because "key" is null
	at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
	at org.glassfish.exousia.modules.def.DefaultPolicyConfigurationFactory.getCurrentPolicyConfiguration(DefaultPolicyConfigurationFactory.java:81)
	at org.glassfish.exousia.modules.def.DefaultPolicy.getPermissions(DefaultPolicy.java:146)
	at java.base/java.security.Policy.initPolicy(Policy.java:347)
	at java.base/java.security.Policy.setPolicy(Policy.java:289)
	at org.glassfish.exousia.AuthorizationService.installPolicy(AuthorizationService.java:591)
	at org.glassfish.exousia.AuthorizationService.<init>(AuthorizationService.java:128)
	at org.glassfish.exousia.AuthorizationService.<init>(AuthorizationService.java:120)
	at org.glassfish.exousia.AuthorizationService.<init>(AuthorizationService.java:102)
	at org.glassfish.exousia.spi.tomcat.TomcatAuthorizationFilter.init(TomcatAuthorizationFilter.java:76)
	at jakarta.servlet.GenericFilter.init(GenericFilter.java:73)
	at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:273)
	at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254)
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:103)
	at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4562)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5205)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
	at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1027)
	at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:2001)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123)
	at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:828)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:478)
	at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1757)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:316)
	at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
	at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1162)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1365)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1369)
	at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1347)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.base/java.lang.Thread.run(Thread.java:833)

[arjantijms]

This is likely the same issue as encountered with Exousia on Piranha cloud. Upon a redeploy it picks up the previous Policy, which is the Policy it set itself then but from the last class loader.

The simplest workaround is to just null the previous one, as done here: piranhacloud/piranha@f841972

Delegating to the previous Policy is needed for when a Java SE security manager is installed, and the Jakarta EE and Java SE permissions are mixed (which I think has always been weird to begin with).