[Red Hat JIRA] (WFLY-14115) Tests failures in multinode with security manager enabled affect other tests
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-14115?page=com.atlassian.jira.plugi... ]
Lin Gao reassigned WFLY-14115:
------------------------------
Assignee: Tomasz Adamski (was: Lin Gao)
> Tests failures in multinode with security manager enabled affect other tests
> ----------------------------------------------------------------------------
>
> Key: WFLY-14115
> URL: https://issues.redhat.com/browse/WFLY-14115
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Lin Gao
> Assignee: Tomasz Adamski
> Priority: Minor
>
> In *+testsuite/integration/multinode+*, when security manager is enabled, the xa recovery files failed be deleted because of no permission when tests finished, it affects other tests so that the Periodic Recovery thread will try to recover the failed transactions.
> * Failed EjbOverHttpWrongCredentialsTestCase:
> {code:java}
> 12:45:15,778 WARN [com.arjuna.ats.jta] (pool-20-thread-1) ARJUNA016039: onePhaseCommit on < formatId=131077, gtri
> d_length=29, bqual_length=36, tx_uid=0:ffff7f000001:659146d8:5fbc8fc0:e5, node_name=1, branch_uid=0:ffff7f000001:659146d8:5fbc8fc0:eb, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at http://localhost:8180/wildfly-services) failed with exception -: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/lgao/sources/jboss/wildfly/testsuite/integration/multinode/target/jbossas-multinode-client/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffff7f000001659146d85fbc8fc0000000e531_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "delete")" in code source "(vfs:/content/ejboverhttp-test-client-wrong-credentials.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejboverhttp-test-client-wrong-credentials.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:304)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:201)
> at java.lang.SecurityManager.checkDelete(SecurityManager.java:1007)
> at org.wildfly.security.manager.WildFlySecurityManager.checkDelete(WildFlySecurityManager.java:393)
> at sun.nio.fs.UnixPath.checkDelete(UnixPath.java:807)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:222)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.removeResource(FileSystemXAResourceRegistry.java:298)
> at org.wildfly.transaction.client.SubordinateXAResource.commit(SubordinateXAResource.java:188)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:702)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2395)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> {code}
> * Affected EjbOverHttpTestCase:
> {code:java}
> 12:45:18,745 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0})
> at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:237)
> at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:659)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:240)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: java.io.IOException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0})
> at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:235)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (WFLY-14033) app-client unable to inject EJB unless also deployed locally to app client process
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-14033?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-14033:
-----------------------------------------
[~istudens] FYI now may not be the time for this one.
> app-client unable to inject EJB unless also deployed locally to app client process
> ----------------------------------------------------------------------------------
>
> Key: WFLY-14033
> URL: https://issues.redhat.com/browse/WFLY-14033
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Reporter: Darran Lofthouse
> Assignee: Ivo Studensky
> Priority: Major
> Fix For: 22.0.0.Beta1
>
>
> The current app-client quickstart uses a single ear for both server side and client side, this did not make sense as it means the EJBs are also deployed to the client process even though the client process is invoking remote EJBs exclusively.
> I have attempted some refactoring to make the quickstart clearer so users can see the server side requirement and the client side requirement:
> https://github.com/darranl/wildfly-quickstart/tree/WFLY-14027
> The problem is starting app-client now fails with this error:
> {code}
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.appclient.server.api.StatelessSession' for binding org.jboss.as.quickstarts.appclient.acc.client.Main/slsb
> at org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:271)
> at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:242)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:246)
> at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:160)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182) [wildfly-server-14.0.0.Beta1.jar:14.0.0.Beta1]
> ... 8 more
> {code}
> This feels as though the injection should either be a proxy which has not yet connected to the remote process or should connect to the remote process first to identify the available beans.
> The reason for delayed connection may be to enable authentication before the application uses the EJBs but deploying server side components on the client doesn't feel like the correct solution.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (WFLY-14140) (7.3.z) Tests failures in multinode with security manager enabled affect other tests
by Lin Gao (Jira)
Lin Gao created WFLY-14140:
------------------------------
Summary: (7.3.z) Tests failures in multinode with security manager enabled affect other tests
Key: WFLY-14140
URL: https://issues.redhat.com/browse/WFLY-14140
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Lin Gao
Assignee: Tomasz Adamski
In *+testsuite/integration/multinode+*, when security manager is enabled, the xa recovery files failed be deleted because of no permission when tests finished, it affects other tests so that the Periodic Recovery thread will try to recover the failed transactions.
* Failed EjbOverHttpWrongCredentialsTestCase:
{code:java}
12:45:15,778 WARN [com.arjuna.ats.jta] (pool-20-thread-1) ARJUNA016039: onePhaseCommit on < formatId=131077, gtri
d_length=29, bqual_length=36, tx_uid=0:ffff7f000001:659146d8:5fbc8fc0:e5, node_name=1, branch_uid=0:ffff7f000001:659146d8:5fbc8fc0:eb, subordinatenodename=null, eis_name=unknown eis name > (Subordinate XAResource at http://localhost:8180/wildfly-services) failed with exception -: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/lgao/sources/jboss/wildfly/testsuite/integration/multinode/target/jbossas-multinode-client/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffff7f000001659146d85fbc8fc0000000e531_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" "delete")" in code source "(vfs:/content/ejboverhttp-test-client-wrong-credentials.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejboverhttp-test-client-wrong-credentials.jar" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:304)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:201)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:1007)
at org.wildfly.security.manager.WildFlySecurityManager.checkDelete(WildFlySecurityManager.java:393)
at sun.nio.fs.UnixPath.checkDelete(UnixPath.java:807)
at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:222)
at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
at java.nio.file.Files.delete(Files.java:1126)
at org.wildfly.transaction.client.provider.jboss.FileSystemXAResourceRegistry$XAResourceRegistryFile.removeResource(FileSystemXAResourceRegistry.java:298)
at org.wildfly.transaction.client.SubordinateXAResource.commit(SubordinateXAResource.java:188)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:702)
at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2395)
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
{code}
* Affected EjbOverHttpTestCase:
{code:java}
12:45:18,745 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0})
at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:237)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:233)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:659)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:240)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: java.io.IOException: WFHTTP000005: Invalid response code 404 (full response ClientResponse{responseHeaders={content-length=[74], content-type=[text/html], date=[Tue, 24 Nov 2020 04:45:18 GMT]}, responseCode=404, status='', protocol=HTTP/2.0})
at org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:235)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (DROOLS-5880) Revisit Kie/Drools maven archetype
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5880?page=com.atlassian.jira.plug... ]
Matteo Mortari reassigned DROOLS-5880:
--------------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> Revisit Kie/Drools maven archetype
> ----------------------------------
>
> Key: DROOLS-5880
> URL: https://issues.redhat.com/browse/DROOLS-5880
> Project: Drools
> Issue Type: Story
> Components: integration
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> *Motivation*: currently the only 1 available Kie maven archetype for Drools shows sign of age.
> *Goals*: reconsidering the following aspects:
> * contains only a mirror test (generated folder/file structure) but doesn't actually "use" the generated project so if it breaks we don't know. Potentially add a maven invoker test in droolsjbpm-integration to check it.
> * License header: do as Camel / Quarkus do, the end result, the user files, do NOT contain a Red Hat license header. Can be resolved by template engine comment like Camel team did.
> * the current Drools unit test is not very significative, always check that "type==color" maybe add some Measurement not of type color to get the test more significative
> * currently Stateful Vs CEP test is governed by variable during archetype generation. Experience shows this is overlooked. It is best to actually separate this into 2 separate Archetypes.
> * currently defines Eclipse IDE exclusion in the generated pom.xml, maybe just easier to:
> ** always generate it
> ** bring that into the kie-maven-plugin, albeit it may require providing the xml file manually. Here it could be worthy to check how Quarkus team resolved this issue
> *Impacts*: archetypes are directly used by end-users when creating a project, but IIRC there is no mention in the Docs (for "v7x series" / Kie)
> /cc [~lucamolteni][~danielezonca]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (DROOLS-5880) Revisit Kie/Drools maven archetype
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-5880:
--------------------------------------
Summary: Revisit Kie/Drools maven archetype
Key: DROOLS-5880
URL: https://issues.redhat.com/browse/DROOLS-5880
Project: Drools
Issue Type: Story
Components: integration
Reporter: Matteo Mortari
Assignee: Mario Fusco
*Motivation*: currently the only 1 available Kie maven archetype for Drools shows sign of age.
*Goals*: reconsidering the following aspects:
* contains only a mirror test (generated folder/file structure) but doesn't actually "use" the generated project so if it breaks we don't know. Potentially add a maven invoker test in droolsjbpm-integration to check it.
* License header: do as Camel / Quarkus do, the end result, the user files, do NOT contain a Red Hat license header. Can be resolved by template engine comment like Camel team did.
* the current Drools unit test is not very significative, always check that "type==color" maybe add some Measurement not of type color to get the test more significative
* currently Stateful Vs CEP test is governed by variable during archetype generation. Experience shows this is overlooked. It is best to actually separate this into 2 separate Archetypes.
* currently defines Eclipse IDE exclusion in the generated pom.xml, maybe just easier to:
** always generate it
** bring that into the kie-maven-plugin, albeit it may require providing the xml file manually. Here it could be worthy to check how Quarkus team resolved this issue
*Impacts*: archetypes are directly used by end-users when creating a project, but IIRC there is no mention in the Docs (for "v7x series" / Kie)
/cc [~lucamolteni][~danielezonca]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (DROOLS-5878) Fix "ApplyPmmlModelCommand.isMining()" implementation
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5878?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5878:
-------------------------------------
Description:
Currently, ApplyPmmlModelCommand.isMining() is a little bit contrived and SONAR raise warning
Fix it and add appropriate test
was:
Currently, ApplyPmmlModelCommand.isMining() has two main issues
1) is contrived
2) it seems to return wrong values due to a doubled/wrong negation
{code:java}
if (hasMining == null || !hasMining.booleanValue() == false) {
return false;
{code}
Fix it and add appropriate test
> Fix "ApplyPmmlModelCommand.isMining()" implementation
> -----------------------------------------------------
>
> Key: DROOLS-5878
> URL: https://issues.redhat.com/browse/DROOLS-5878
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Critical
> Labels: TrustyAI
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Currently, ApplyPmmlModelCommand.isMining() is a little bit contrived and SONAR raise warning
> Fix it and add appropriate test
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[Red Hat JIRA] (DROOLS-5879) Optional newline handling in MVEL parser
by Edoardo Vacchi (Jira)
Edoardo Vacchi created DROOLS-5879:
--------------------------------------
Summary: Optional newline handling in MVEL parser
Key: DROOLS-5879
URL: https://issues.redhat.com/browse/DROOLS-5879
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Edoardo Vacchi
Assignee: Edoardo Vacchi
MVEL parser explicitly handles newlines so that statements can be terminated automatically without semicolons.
However, in some situations this is not necessary. For instance, while parsing constraints, newlines should be treated as non-significant whitespace.
We add support to a new lexer state, that can be switched at run-time (parser instantiation time), to allow for whitespace to be fully ignored, newlines included.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months