[JBoss JIRA] (WFLY-8110) Submitting work with distributed workmanager fails with null securityIntegration
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-8110?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-8110:
--------------------------------
Description:
I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
{code}
javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: Null security integration
at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.java:76)
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:240)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
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:240)
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
... 40 more
{code}
The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
I found that an ordinary workmanager service contains the following:
{{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
There might be some concerns about Elytron integration too, but I leave that to [~msimka].
I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.
Found with commit: 8d587934b771cf91425ea3e06d23dcd7f145e9ef
was:
When implementing tests for EAP7-495, I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
{code}
javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: Null security integration
at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.java:76)
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:240)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85)
at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
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:240)
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
... 40 more
{code}
The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
I found that an ordinary workmanager service contains the following:
{{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
There might be some concerns about Elytron integration too, but I leave that to [~msimka].
I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.
> Submitting work with distributed workmanager fails with null securityIntegration
> --------------------------------------------------------------------------------
>
> Key: WFLY-8110
> URL: https://issues.jboss.org/browse/WFLY-8110
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Alpha1
> Reporter: Richard Janík
> Assignee: Stefano Maestri
> Priority: Critical
>
> I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
> {code}
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Null security integration
> at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
> at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
> at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
> at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
> at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
> at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.java:76)
> 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:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:240)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 40 more
> {code}
> The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
> I found that an ordinary workmanager service contains the following:
> {{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
> and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
> Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
> There might be some concerns about Elytron integration too, but I leave that to [~msimka].
> I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.
> Found with commit: 8d587934b771cf91425ea3e06d23dcd7f145e9ef
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8110) Submitting work with distributed workmanager fails with null securityIntegration
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-8110?page=com.atlassian.jira.plugin.... ]
Richard Janík moved JBEAP-8822 to WFLY-8110:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8110 (was: JBEAP-8822)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR11)
> Submitting work with distributed workmanager fails with null securityIntegration
> --------------------------------------------------------------------------------
>
> Key: WFLY-8110
> URL: https://issues.jboss.org/browse/WFLY-8110
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 11.0.0.Alpha1
> Reporter: Richard Janík
> Assignee: Stefano Maestri
> Priority: Critical
>
> When implementing tests for EAP7-495, I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
> {code}
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalArgumentException: Null security integration
> at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
> at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
> at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
> at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
> at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
> at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.java:76)
> 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:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:85)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:96)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:240)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 40 more
> {code}
> The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
> I found that an ordinary workmanager service contains the following:
> {{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
> and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
> Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
> There might be some concerns about Elytron integration too, but I leave that to [~msimka].
> I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE TS
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugi... ]
Marek Kopecký updated WFCORE-2294:
----------------------------------
Description:
Improve timeouts in WF-CORE TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner
* CliProcessWrapper.java should use TimeoutUtil for timeout
This stabilizes TS on slower machines.
was:
Improve timeouts in WF-CORE TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner
* CliProcessWrapper.java should use TimeoutUtil for timeout
> Improve timeouts in WF-CORE TS
> ------------------------------
>
> Key: WFCORE-2294
> URL: https://issues.jboss.org/browse/WFCORE-2294
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha22
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> Improve timeouts in WF-CORE TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner
> * CliProcessWrapper.java should use TimeoutUtil for timeout
> This stabilizes TS on slower machines.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-8109:
--------------------------------
Description:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integrati...]
This stabilizes TS on slower machines.
was:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integrati...]
> Improve timeouts in AS TS
> -------------------------
>
> Key: WFLY-8109
> URL: https://issues.jboss.org/browse/WFLY-8109
> Project: WildFly
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase timeout in LegacyConfigTest
> * increase timeout in DomainHostExcludesTest
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integrati...]
> This stabilizes TS on slower machines.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-8109:
-----------------------------------
Summary: Improve timeouts in AS TS
Key: WFLY-8109
URL: https://issues.jboss.org/browse/WFLY-8109
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: Marek Kopecký
Assignee: Marek Kopecký
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integrati...]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7164) Complex type http-authentication-factory in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7164?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7164:
-----------------------------
Description:
Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
Complex attributes in add operation and resource description:
mechanism-configurations
mechanism-realm-configurations.
was:Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex type http-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
> Key: WFLY-7164
> URL: https://issues.jboss.org/browse/WFLY-7164
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex attributes in add operation and resource description:
> mechanism-configurations
> mechanism-realm-configurations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1548) Access denied when deploying to wildfly 10
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1548:
-------------------------------------
If issue only occurs when antirvirus/antimalware/application firewall is running and causing this.
I don't see how we could fix that in our code as it is out of our hands what OS (and its tools) do to files / folders we try to access.
It is annoying but more problem with antivirus/antimalware than anything else.
> Access denied when deploying to wildfly 10
> ------------------------------------------
>
> Key: WFCORE-1548
> URL: https://issues.jboss.org/browse/WFCORE-1548
> Project: WildFly Core
> Issue Type: Bug
> Environment: Wildfly 10, Windows 7, java 1.8_05, maven 3.0.5, maven 3.3.9
> Reporter: Srecko Mandelj
> Assignee: James Perkins
> Priority: Minor
> Attachments: TestMavenPlugin.zip, server.log
>
>
> I have a war application containing web services. I have no problems deploying war to wildfly 8.1. After upgrade to wildfly 10, the plugin doesn't work any more. I get this error when trying to deploy:
> {code}
> [Server:server-one] 09:36:51,162 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 132) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/ActivatorFrontEnd'
> [Server:server-one] 09:36:51,220 SEVERE [javax.enterprise.resource.webcontainer.
> jsf.config] (ServerService Thread Pool -- 132) Critical error during deployment:
> : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: javax.faces.FacesException: java.io.FileNotFoundException: C:\podatki\jboss_configurations\wildfly10\domainController\servers\server-one\tmp\vfs\temp\temp1e3a1daf9121b0e4\content-34b685741ee5aeb4\content-6322725066713898564.tmp (Access is denied)
> {code}
> It looks like a concurrency issue - one process is trying to use a file that other process is using. If I deploy through web console or via CLI, I don't have this issue. It is somehow related to jsf implementation. If I remove jsf from wildfly configuration file (the module and subsystem), deploy works ok (Mojara is then not triggered and deploy is successful).
> I tried to deploy with 1.1.9.Alpha8, but I get the same error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7175) Complex type server-ssl-context/ssl-session in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7175?page=com.atlassian.jira.plugin.... ]
Jan Kalina reopened WFLY-7175:
------------------------------
Forgot to update definitions, updated in handlers only...
> Complex type server-ssl-context/ssl-session in Elytron subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-7175
> URL: https://issues.jboss.org/browse/WFLY-7175
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in server-ssl-context resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Details: *server-ssl-context/ssl-session* - nested complex attributes (not critical in the short term - although exposing management information that provides insight into the current sessions would be a big bonus for administrators)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8108) Elytron subsystem is unable to configure SunPKCS11 provider
by Martin Choma (JIRA)
Martin Choma created WFLY-8108:
----------------------------------
Summary: Elytron subsystem is unable to configure SunPKCS11 provider
Key: WFLY-8108
URL: https://issues.jboss.org/browse/WFLY-8108
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Trying to configure server to run in FIPS mode using subsystem capabilities.
I can't configure throught subsystem same as in java.security file:
{code:title=java.security}
security.provider.1=sun.security.pkcs11.SunPKCS11 /usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg
{code}
because if I try to pass configuration file or configuration
{code}
/subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], path=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/pkcs11.cfg)
/subsystem=elytron/provider-loader=fips:add(class-names=[sun.security.pkcs11.SunPKCS11], configuration={ \
name=nssModule, value=fips \
name=nssSecmodDirectory, value=/usr/java/jdk1.8.0_66_fips_mode/__fips_config_material/fipsdb \
name=nssLibraryDirectory, value=/usr/lib64 \
name=name, value=testPkcs \
name=nssDbMode, value=readOnly \
}
{code}
I get exception
{code}
10:46:28,630 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.providers.fips: org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:185)
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:143)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.ProviderException: SunPKCS11 requires configuration file argument
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:98)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:156)
... 7 more
10:46:28,630 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("provider-loader" => "fips")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.fips" => "org.jboss.msc.service.StartException in service org.wildfly.security.providers.fips: java.security.ProviderException: SunPKCS11 requires configuration file argument
Caused by: java.security.ProviderException: SunPKCS11 requires configuration file argument"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.providers.fips"]
}
{code}
It occures because loading of providers is in subsystem implemented in 2 steps
* create provider instance (call noargs constructor)
* optionally load configuration
But {{sun.security.pkcs11.SunPKCS11}} can't be created without configuration [1]
[1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months