[JBoss JIRA] (WFLY-12171) EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
by James Perkins (Jira)
James Perkins created WFLY-12171:
------------------------------------
Summary: EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
Key: WFLY-12171
URL: https://issues.jboss.org/browse/WFLY-12171
Project: WildFly
Issue Type: Bug
Components: EJB, Security Manager
Reporter: James Perkins
Assignee: Cheng Fang
The EJB client requires write permissions for the {{$JBOSS_HOME/standalone/data/ejb-xa-recovery}} as well as all files in that directory.
{code:title=Example Policy}
grant {
permission java.io.FilePermission
"/opt/wildfly/standalone/data/ejb-xa-recovery", "read-write";
permission java.io.FilePermission
"/opt/wildfly/standalone/data/ejb-xa-recovery/-", "read-write";
};
{code}
{code:title=Example Exception}
javax.ejb.EJBException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:488)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.lambda$handleDone$0(RemoteEJBReceiver.java:91)
at org.xnio.FinishedIoFuture.addNotifier(FinishedIoFuture.java:79)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:76)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:74)
at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
at org.xnio.IoUtils$2.execute(IoUtils.java:71)
at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:130)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491)
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:70)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:110)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:67)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:205)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:333)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:187)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy283.twoSecondEcho(Unknown Source)
at org.jboss.as.test.integration.ejb.client.descriptor.EchoBean.twoSecondEcho(EchoBean.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:237)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:591)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:572)
at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:205)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
at org.wildfly.security.manager.WildFlySecurityManager.checkWrite(WildFlySecurityManager.java:377)
at java.io.File.mkdir(File.java:1311)
at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.<init>(FileSystemXAResourceRegistry.java:207)
at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry.getXAResourceRegistryFile(FileSystemXAResourceRegistry.java:121)
at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider.getXAResourceRegistry(JBossLocalTransactionProvider.java:160)
at org.wildfly.transaction.client.XAOutflowedResources.getOrEnlist(XAOutflowedResources.java:57)
at org.wildfly.transaction.client.RemoteTransactionContext.outflowTransaction(RemoteTransactionContext.java:222)
at org.jboss.ejb.protocol.remote.EJBClientChannel.writeTransaction(EJBClientChannel.java:586)
at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:384)
... 96 more
{code}
Full chat conversion: https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
{quote}
David Lloyd: the notifier is running in the same thread because the response was available quickly enough
David Lloyd: when that happens you get the permission exception because the test class doesn't have the filesystem permissions
David Lloyd: the easy fix would be to grant that perm to the test
David Lloyd: slightly more elegant would be to introduce a new permission that would grant the ability to outflow transactions and grant that permission, and use a doPrivileged inside the outflow code
{quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12171) EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12171?page=com.atlassian.jira.plugin... ]
James Perkins reassigned WFLY-12171:
------------------------------------
Assignee: (was: Cheng Fang)
> EJB Client requires FilePermission for ejb-xa-recovery with security manager enabled
> ------------------------------------------------------------------------------------
>
> Key: WFLY-12171
> URL: https://issues.jboss.org/browse/WFLY-12171
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security Manager
> Reporter: James Perkins
> Priority: Major
>
> The EJB client requires write permissions for the {{$JBOSS_HOME/standalone/data/ejb-xa-recovery}} as well as all files in that directory.
> {code:title=Example Policy}
> grant {
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery", "read-write";
> permission java.io.FilePermission
> "/opt/wildfly/standalone/data/ejb-xa-recovery/-", "read-write";
> };
> {code}
> {code:title=Example Exception}
> javax.ejb.EJBException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:488)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.lambda$handleDone$0(RemoteEJBReceiver.java:91)
> at org.xnio.FinishedIoFuture.addNotifier(FinishedIoFuture.java:79)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:76)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver$1.handleDone(RemoteEJBReceiver.java:74)
> at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
> at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
> at org.xnio.IoUtils$2.execute(IoUtils.java:71)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
> at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
> at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
> at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:130)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:491)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:70)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:110)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:67)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:205)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:506)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:333)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:187)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy283.twoSecondEcho(Unknown Source)
> at org.jboss.as.test.integration.ejb.client.descriptor.EchoBean.twoSecondEcho(EchoBean.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:237)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:591)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:572)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:205)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/basic/target/wildfly/standalone/data/ejb-xa-recovery" "write")" in code source "(vfs:/content/ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb-client-descriptor-test-with-jboss-ejb-client_1_2_xml.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> at org.wildfly.security.manager.WildFlySecurityManager.checkWrite(WildFlySecurityManager.java:377)
> at java.io.File.mkdir(File.java:1311)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.<init>(FileSystemXAResourceRegistry.java:207)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry.getXAResourceRegistryFile(FileSystemXAResourceRegistry.java:121)
> at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider.getXAResourceRegistry(JBossLocalTransactionProvider.java:160)
> at org.wildfly.transaction.client.XAOutflowedResources.getOrEnlist(XAOutflowedResources.java:57)
> at org.wildfly.transaction.client.RemoteTransactionContext.outflowTransaction(RemoteTransactionContext.java:222)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.writeTransaction(EJBClientChannel.java:586)
> at org.jboss.ejb.protocol.remote.EJBClientChannel.processInvocation(EJBClientChannel.java:384)
> ... 96 more
> {code}
> Full chat conversion: https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
> {quote}
> David Lloyd: the notifier is running in the same thread because the response was available quickly enough
> David Lloyd: when that happens you get the permission exception because the test class doesn't have the filesystem permissions
> David Lloyd: the easy fix would be to grant that perm to the test
> David Lloyd: slightly more elegant would be to introduce a new permission that would grant the ability to outflow transactions and grant that permission, and use a doPrivileged inside the outflow code
> {quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4137) KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
by Justin Holmes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4137?page=com.atlassian.jira.plugi... ]
Justin Holmes updated DROOLS-4137:
----------------------------------
Description:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates. If we can get a working build, we would be happy to submit a doc fix.
We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
was:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates.
We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
> KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-4137
> URL: https://issues.jboss.org/browse/DROOLS-4137
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Priority: Major
>
> I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
> See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
> Documentation is VERY limited / scattered in different areas. It probably needs updates. If we can get a working build, we would be happy to submit a doc fix.
> We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4137) KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
by Justin Holmes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4137?page=com.atlassian.jira.plugi... ]
Justin Holmes updated DROOLS-4137:
----------------------------------
Description:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates. If we can get help to get the build working / bug fixed, we would be happy to submit a doc fix.
We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
was:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates. If we can get a working build, we would be happy to submit a doc fix.
We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
> KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-4137
> URL: https://issues.jboss.org/browse/DROOLS-4137
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Priority: Major
>
> I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
> See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
> Documentation is VERY limited / scattered in different areas. It probably needs updates. If we can get help to get the build working / bug fixed, we would be happy to submit a doc fix.
> We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4137) KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
by Justin Holmes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4137?page=com.atlassian.jira.plugi... ]
Justin Holmes updated DROOLS-4137:
----------------------------------
Description:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates.
We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
was:
I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
Documentation is VERY limited / scattered in different areas. It probably needs updates.
> KIE Maven Plugin Fails to Load Dependencies for KieBase when Serializing KieBase During Build
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-4137
> URL: https://issues.jboss.org/browse/DROOLS-4137
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.22.0.Final
> Reporter: Justin Holmes
> Assignee: Mario Fusco
> Priority: Major
>
> I would like to have kie-maven-plugin build the KJar with a serialized KieBase so that it takes less time to boot strap drools. It appears that the maven configuration used by the kie-maven-plugin is broken, or at least there is not sufficient documentation to set it up.
> See https://groups.google.com/forum/#!topic/drools-setup/0TZvE5lpcto for more information.
> Documentation is VERY limited / scattered in different areas. It probably needs updates.
> We are trying to use drools in a severless environment (though not quite ready for Quarkus). If we are unable to use this build feature, we may be unable to use drools.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12031:
---------------------------------------
I other words, [~petrjoac] and [~cfang] the delete statement is unreachable without the fix for WFTC-62
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Flavia Rainone (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Flavia Rainone commented on WFLY-12031:
---------------------------------------
[~petrjoac] please test with the aforementioned PR. This fix will probably solve your problem, because if (resources.remove(resource) was always returning false as the resource was not being added at all to the list.
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months