[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1199:
------------------------------------------
[~ryanemerson] Please don't reopen community issues after the version shown in Fix Version has been released as a .Final. Please file a new issue and link it.
> CLI Lists in non-interactive mode are erroneously split into multiple commands
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1199
> URL: https://issues.jboss.org/browse/WFCORE-1199
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules, Patching
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 2.0.8.Final
>
>
> The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of:
> "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2"
> the cli is incorrectly splitting the request into two distinct commands:
> 1. module add --name=test --resources=test.jar --dependencies=dep1
> 2. dep2
> The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd.
> This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6130) Upgrade Resteasy to release 3.0.15.Final
by Ron Sigal (JIRA)
Ron Sigal created WFLY-6130:
-------------------------------
Summary: Upgrade Resteasy to release 3.0.15.Final
Key: WFLY-6130
URL: https://issues.jboss.org/browse/WFLY-6130
Project: WildFly
Issue Type: Component Upgrade
Affects Versions: 10.0.0.Final
Reporter: Ron Sigal
Assignee: Jason Greene
Priority: Blocker
Fix For: 10.1.0.Final
An update to the jaxrs module in TCK7 has caused some tests to fail due to a bug in Resteasy. That bug will be fixed in Resteasy release 3.0.15.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6129) Upgrade Resteasy to release 3.0.15.Final
by Ron Sigal (JIRA)
Ron Sigal created WFLY-6129:
-------------------------------
Summary: Upgrade Resteasy to release 3.0.15.Final
Key: WFLY-6129
URL: https://issues.jboss.org/browse/WFLY-6129
Project: WildFly
Issue Type: Component Upgrade
Affects Versions: 10.0.0.Final
Reporter: Ron Sigal
Assignee: Jason Greene
Priority: Blocker
Fix For: 10.1.0.Final
An update to the jaxrs module in TCK7 has caused some tests to fail due to a bug in Resteasy. That bug will be fixed in Resteasy release 3.0.15.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1199.
--------------------------------------
Resolution: Done
> CLI Lists in non-interactive mode are erroneously split into multiple commands
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1199
> URL: https://issues.jboss.org/browse/WFCORE-1199
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules, Patching
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 2.0.8.Final
>
>
> The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of:
> "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2"
> the cli is incorrectly splitting the request into two distinct commands:
> 1. module add --name=test --resources=test.jar --dependencies=dep1
> 2. dep2
> The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd.
> This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ]
Ryan Emerson commented on WFCORE-1199:
--------------------------------------
Re-opened as I had missed the comma-seperated lists in DeployHandler and UndeployHandler as well as the --properties field for ASModuleHandler in the original commit.
> CLI Lists in non-interactive mode are erroneously split into multiple commands
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1199
> URL: https://issues.jboss.org/browse/WFCORE-1199
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules, Patching
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 2.0.8.Final
>
>
> The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of:
> "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2"
> the cli is incorrectly splitting the request into two distinct commands:
> 1. module add --name=test --resources=test.jar --dependencies=dep1
> 2. dep2
> The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd.
> This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1199) CLI Lists in non-interactive mode are erroneously split into multiple commands
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1199?page=com.atlassian.jira.plugi... ]
Ryan Emerson reopened WFCORE-1199:
----------------------------------
> CLI Lists in non-interactive mode are erroneously split into multiple commands
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1199
> URL: https://issues.jboss.org/browse/WFCORE-1199
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules, Patching
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 2.0.8.Final
>
>
> The problem arises because commands entered in non-interactive mode are split by the "," character. Therefore, in the case of:
> "./bin/jboss-cli.sh -c --controller=localhost --commands="module add --name=test --resources=test.jar --dependencies=dep1,dep2"
> the cli is incorrectly splitting the request into two distinct commands:
> 1. module add --name=test --resources=test.jar --dependencies=dep1
> 2. dep2
> The reason this behaviour is not observed in interactive mode is because multiple commands can not be specified. However, in non-interactive mode --commands=ls,pwd is valid and should result in the execution of ls followed by pwd.
> This problem is not restricted to the module command, as it affects all commands entered in non-interactive mode that require a comma-separated list as an argument. So far this appears to be PatchHanlder.java, ASModuleHandler.java and DeploymentOverlayHandler.java.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-4840) Deprecated element cluster-passivation-store from ejb subsystem does not work
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4840?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4840:
---------------------------------
Priority: Minor (was: Major)
> Deprecated element cluster-passivation-store from ejb subsystem does not work
> -----------------------------------------------------------------------------
>
> Key: WFLY-4840
> URL: https://issues.jboss.org/browse/WFLY-4840
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ondřej Chaloupka
> Assignee: Radoslav Husar
> Priority: Minor
>
> There is a mismatch in behaviour of deprecated element {{cluster-passivation-store}} under {{ejb}} subsystem.
> When element is deprecated still it should work and only prints warning that it's deprecated.
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:read-resource()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"ejb3\"),
> (\"cluster-passivation-store\" => \"infinispan\")
> ]' not found",
> "rolled-back" => true
> }
> {code}
> but
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3/cluster-passivation-store=infinispan:add()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb.cache.factory.distributable.infinispan is already registered",
> "rolled-back" => true
> }
> {code}
> _A note:_ the element {{cluster-passivation-store}} was replaced by {{passivation-store}} which works fine
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6120) SFSB PassivationTestCase fails to resolve XPC following passivation
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6120?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6120:
------------------------------------
I need to debug to see what is going on. Each TestPassivationBean should have its own XPC instance. The TestPassivationBean has a reference to a NestedBean, which shares the same XPC instance. So, it might be okay that two threads are serializing the remote TestPassivationBean beans at the same time. Now, that I understand the app, will debug :-)
> SFSB PassivationTestCase fails to resolve XPC following passivation
> -------------------------------------------------------------------
>
> Key: WFLY-6120
> URL: https://issues.jboss.org/browse/WFLY-6120
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Scott Marlow
>
> javax.ejb.EJBException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it. This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context. See JPA spec 2.0 section 7.6.3.1. Scoped persistence unit name=passivation-test.jar#main, persistence context already in transaction =ExtendedEntityManager [passivation-test.jar#main], extended persistence context =ExtendedEntityManager [passivation-test.jar#main].
> at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:149)
> at org.jboss.as.jpa.container.ExtendedEntityManager.getEntityManager(ExtendedEntityManager.java:129)
> at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:444)
> at org.jboss.as.test.integration.ejb.stateful.passivation.TestPassivationBean.isPersistenceContextSame(TestPassivationBean.java:91)
> 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:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 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:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy72.isPersistenceContextSame(Unknown Source)
> at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6120) SFSB PassivationTestCase fails to resolve XPC following passivation
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6120?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-6120 at 2/4/16 10:50 AM:
-------------------------------------------------------------
>From the gist link mentioned in previous comment, it looks like we are passivating the two beans but passivation is occurring in different threads.
was (Author: smarlow):
>From the gist link mentioned in previous comment, it looks like we are passivating the two beans but passivation is occurring in different threads (implying that we are not passivating the group of beans as one graph).
> SFSB PassivationTestCase fails to resolve XPC following passivation
> -------------------------------------------------------------------
>
> Key: WFLY-6120
> URL: https://issues.jboss.org/browse/WFLY-6120
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Scott Marlow
>
> javax.ejb.EJBException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it. This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context. See JPA spec 2.0 section 7.6.3.1. Scoped persistence unit name=passivation-test.jar#main, persistence context already in transaction =ExtendedEntityManager [passivation-test.jar#main], extended persistence context =ExtendedEntityManager [passivation-test.jar#main].
> at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:149)
> at org.jboss.as.jpa.container.ExtendedEntityManager.getEntityManager(ExtendedEntityManager.java:129)
> at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:444)
> at org.jboss.as.test.integration.ejb.stateful.passivation.TestPassivationBean.isPersistenceContextSame(TestPassivationBean.java:91)
> 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:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 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:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy72.isPersistenceContextSame(Unknown Source)
> at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months