[JBoss JIRA] (WFCORE-1732) "org.jboss.vfs.VirtualFilePermission" by some tests in TS with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1732?page=com.atlassian.jira.plugi... ]
Ivo Studensky moved WFLY-6185 to WFCORE-1732:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1732 (was: WFLY-6185)
Component/s: Server
(was: Test Suite)
> "org.jboss.vfs.VirtualFilePermission" by some tests in TS with security manager
> -------------------------------------------------------------------------------
>
> Key: WFCORE-1732
> URL: https://issues.jboss.org/browse/WFCORE-1732
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> Some tests fails due to java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" while run with security manager enabled.
> *Affected tests found so far:*
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *How to reproduce*
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevel
> * ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase#testSimpleOverrideInEarAtEarLevelExploded
> *Stacktrace*
> {code}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
> at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
> at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
> at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
> at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7000) Batch jobs from installed modules should be detected for non-batch app
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-7000?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7000:
-------------------------------------
JBeret has an API to allow job XML to be loaded from places other than the {{META-INF/batch-jobs}} directory. Currently during deploy if the deployment does not have a {{META-INF/batch-jobs}} directory the loading of the user services is ignored. The loading of user services, or other module services, should be done regardless of the existence of the batch-jobs directory.
> Batch jobs from installed modules should be detected for non-batch app
> ----------------------------------------------------------------------
>
> Key: WFLY-7000
> URL: https://issues.jboss.org/browse/WFLY-7000
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Mincong Huang
> Assignee: James Perkins
>
> Hibernate Search is creating a batch job which embedded in a WildFly module. Any user of Hibernate Search should be able to the launch this batch job, no matter if they're using a batch-app. However, it seems that jobs are only resolvable for batch-app. More explicitly, WildFly requires deployed web-app to have the below structure to enable the job resolver:
> META-INF/batch-jobs
> For those who don't have this batch folder in their webapp, they cannot use the jobs from installed module. And an error "JBERET000601: Failed to get job xml file for job" will be raised.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7003) Batch jobs from installed modules should be detected for non-batch app
by James Perkins (JIRA)
James Perkins created WFLY-7003:
-----------------------------------
Summary: Batch jobs from installed modules should be detected for non-batch app
Key: WFLY-7003
URL: https://issues.jboss.org/browse/WFLY-7003
Project: WildFly
Issue Type: Bug
Components: Batch
Affects Versions: 10.0.0.Final
Reporter: Mincong Huang
Assignee: James Perkins
Hibernate Search is creating a batch job which embedded in a WildFly module. Any user of Hibernate Search should be able to the launch this batch job, no matter if they're using a batch-app. However, it seems that jobs are only resolvable for batch-app. More explicitly, WildFly requires deployed web-app to have the below structure to enable the job resolver:
META-INF/batch-jobs
For those who don't have this batch folder in their webapp, they cannot use the jobs from installed module. And an error "JBERET000601: Failed to get job xml file for job" will be raised.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7001) CLI 'deployment-info --headers' throws errors in standalone mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7001?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7001:
----------------------------------------
This is a WFCORE issue.
> CLI 'deployment-info --headers' throws errors in standalone mode
> ----------------------------------------------------------------
>
> Key: WFLY-7001
> URL: https://issues.jboss.org/browse/WFLY-7001
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> In standalone mode of jboss-cli, the command: 'deployment-info --headers' throws Java exceptions instead of a proper problem description.
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> {code}
> Tab complete does not work beyond '--headers=' and starts working again after '\{' is typed.
> *Example*:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers<TAB>=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={<TAB>
> allow-resource-service-restart rollback-on-runtime-failure
> blocking-timeout rollout
> {code}
> *Steps to reproduce*:
> Standalone:
> {code:bash}
> [standalone@localhost:9990 /] deployment-info --headers
> Failed to perform operation: java.util.concurrent.ExecutionException: Operation failed: Operation failed: java.lang.IllegalArgumentException:null
> [standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB>
> Failed to handle 'deployment-info --headers=': newValue is null
> [standalone@localhost:9990 /] deployment-info --headers={}
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> jboss-kitchensink-ml-ear.ear jboss-kitchensink-ml-ear.ear true false STOPPED
> jboss-kitchensink.war jboss-kitchensink.war true false STOPPED
> jboss-modules.jar jboss-modules.jar true false STOPPED
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on JBJCA-1329:
--------------------------------------
Thanks Stefano!
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1329:
----------------------------------------
It's correct, it's a requirement in jca spec (15.4.4)
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on JBJCA-1329:
--------------------------------------
I am not 100% sure I follow, but it seems like a good time to get rid of the TODO https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
Is the Narayana correct to only allow one or is a change required?
Thanks,
Tom
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months