[JBoss JIRA] (WFLY-9046) org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9046?page=com.atlassian.jira.plugin.... ]
Chao Wang updated WFLY-9046:
----------------------------
Component/s: Security Manager
> org.jboss.as.test.integration.ee.concurrent.Default* fail with security manager
> -------------------------------------------------------------------------------
>
> Key: WFLY-9046
> URL: https://issues.jboss.org/browse/WFLY-9046
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Chao Wang
>
> org.jboss.as.test.integration.ee.concurrent.Default* tests fail with security manager. There are missing permissions "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")":
> {noformat}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.wildfly.security.auth.server.SecurityDomain.getCurrent(SecurityDomain.java:155)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "transaction is not in a valid state" during a 2clusters test
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
kobogian hitis commented on WFLY-6224:
--------------------------------------
Same issue here. Is there a workaround for wildfly 10.0.0.Final?
> IllegalStateException "transaction is not in a valid state" during a 2clusters test
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6224
> URL: https://issues.jboss.org/browse/WFLY-6224
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Beta1
>
>
> During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{IllegalStateException: Transaction is not in a valid state to be invoking cache operations on}}:
> {code}
> 05:12:09,813 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-40) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=352}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:85)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:238)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.release(DistributableCache.java:137)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:168)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doOnePhaseCommit(SubordinateAtomicAction.java:247)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doOnePhaseCommit(TransactionImple.java:283)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:85)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> at org.jboss.as.ejb3.remote.protocol.versionone.TransactionRequestHandler.processMessage(TransactionRequestHandler.java:139)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 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)
> {code}
> The difference from WFLY-4678 is the circumstances.
> In the following text, I'm refering to the nodes by their real names: {{perf17}} is the standalone EJB client, the "forwarder" cluster is {{perf20}} and {{perf21}}, and the "target" cluster is {{perf18}} and {{perf19}}.
> The stack trace above is the first occurence of the exception, it appears on perf19 (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...). At that time, perf18 is just shutting down gracefully, but the perf19 log clearly shows that both Infinispan and JGroups have already figured out that perf18 went away. Still, the absence of graceful shutdown for transactions might be an explanation... except that there's no reason why the cache on perf19 would be in an invalid state if it's perf18 who is going down. So maybe perf19 had to reach out to perf18 for some reason and the exception actually comes from perf18... but the cache is REPL, so perf19 should have all data locally already and it shouldn't really have to reach out to perf18.
> So, not really sure why it happens.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9051) Upgrade JBeret to version 1.2.4.Final
by James Perkins (JIRA)
James Perkins created WFLY-9051:
-----------------------------------
Summary: Upgrade JBeret to version 1.2.4.Final
Key: WFLY-9051
URL: https://issues.jboss.org/browse/WFLY-9051
Project: WildFly
Issue Type: Component Upgrade
Components: Batch
Reporter: James Perkins
Assignee: James Perkins
Fix For: 11.0.0.Beta1
JBeret needs to be upgraded to version 1.2.4.Final to fix JBEAP-11818. There is also a fix for WFLY-3424 and possibly one needed for WFLY-8942.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-8942:
-------------------------------------
I think we may need something like:
{code:java}
final RequestContext requestContext = beanManager.instance().select(RequestContext.class).get();
requestContext.activate();
// do stuff
requestContext.deactivate();
{code}
However that may require a {{BatchRequestContext}} type so that it's not ambiguous. I'm not sure where this all should live. It seems like it should be part of the WildFly Weld Maven module, however I didn't see a way to register a context during the Weld container start up. It's possible I'm just missing it though.
> Request Scope is not active during Batchlet
> -------------------------------------------
>
> Key: WFLY-8942
> URL: https://issues.jboss.org/browse/WFLY-8942
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 Final
> Reporter: Cody Lerum
> Assignee: James Perkins
> Attachments: batch-chunk.war
>
>
> When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted.
> Example
> {noformat}
> 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-8942:
--------------------------------
Steps to Reproduce:
Execute a batch operation and Inject and use an RequestScoped bean within the batchlet.
Deploy the attached WAR and go to http://localhost:8080/batch-chunk/start?jobXml=test-batchlet
was:Execute a batch operation and Inject and use an RequestScoped bean within the batchlet
> Request Scope is not active during Batchlet
> -------------------------------------------
>
> Key: WFLY-8942
> URL: https://issues.jboss.org/browse/WFLY-8942
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 Final
> Reporter: Cody Lerum
> Assignee: James Perkins
> Attachments: batch-chunk.war
>
>
> When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted.
> Example
> {noformat}
> 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months