March 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3122?page=com.atlassian.jira.plugin... ] Mayank Kunwar reassigned JBTM-3122: ----------------------------------- Assignee: Mayank Kunwar (was: Ondrej Chaloupka) > jbosstm/quickstarts tests can't be run with jdk9+ > ------------------------------------------------- > > Key: JBTM-3122 > URL: https://issues.redhat.com/browse/JBTM-3122 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.9.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). > The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}. > See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 > {code} > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED > --add-modules=java.se > {code} > The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. > Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3088) NPE in Recovery Manager

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3088?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3088: ----------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/1563 > NPE in Recovery Manager > ----------------------- > > Key: JBTM-3088 > URL: https://issues.redhat.com/browse/JBTM-3088 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.0.Final > Reporter: Vadim Lotarev > Assignee: Ondrej Chaloupka > Priority: Major > > NPE happens during Recovery: > Dec 12 00:01:54.559 WARN [][Periodic Recovery] ARJUNA016009: Caught: (com.arjuna.ats.jta:) > java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:713) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:494) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:245) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3088) NPE in Recovery Manager

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3088?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3088: ---------------------------------------- My trouble happens when the recovery runs on the Remote EJB XAResource and authentication is wrongly setup. In such case the call to `recover` throws an exception. https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... On the follow-up call during the second pass of recovery the `NPE` may be obtained https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... The stacktrace of the exception I work with is {code} WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:96) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:203) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:210) at org.wildfly.transaction.client@1.1.7.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:206) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried: JBOSS-LOCAL-USER: org.wildfly.security.auth.AuthenticationException: JBREM000300: Authentication failed due to I/O error at org.jboss.remoting@5.0.15.Final//org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:379) at org.jboss.remoting@5.0.15.Final//org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:183) at org.jboss.remoting@5.0.15.Final//org.jboss.remoting3.EndpointImpl$3.lambda$handleDone$0(EndpointImpl.java:529) at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.base/java.lang.Thread.run(Thread.java:834) WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:738) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:519) at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:270) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) {code} > NPE in Recovery Manager > ----------------------- > > Key: JBTM-3088 > URL: https://issues.redhat.com/browse/JBTM-3088 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.0.Final > Reporter: Vadim Lotarev > Assignee: Ondrej Chaloupka > Priority: Major > > NPE happens during Recovery: > Dec 12 00:01:54.559 WARN [][Periodic Recovery] ARJUNA016009: Caught: (com.arjuna.ats.jta:) > java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:713) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:494) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:245) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3088) NPE in Recovery Manager

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3088?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka reopened JBTM-3088: ------------------------------------ Assignee: Ondrej Chaloupka I think do experience this same issue. Regardless, I assume ability to throw the `NullPointerException` is a wrong in any case. > NPE in Recovery Manager > ----------------------- > > Key: JBTM-3088 > URL: https://issues.redhat.com/browse/JBTM-3088 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.0.Final > Reporter: Vadim Lotarev > Assignee: Ondrej Chaloupka > Priority: Major > > NPE happens during Recovery: > Dec 12 00:01:54.559 WARN [][Periodic Recovery] ARJUNA016009: Caught: (com.arjuna.ats.jta:) > java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:713) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:494) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:245) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[narayana-jta-5.9.0.Final.jar.9186195290256057980.jar:5.9.0.Final (revision: f0935)] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3137?page=com.atlassian.jira.plugin... ] Mayank Kunwar commented on JBTM-3137: ------------------------------------- There was also a issue with passing JMH arguments using command line, so did a correction over there as well. > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.redhat.com/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3137?page=com.atlassian.jira.plugin... ] Mayank Kunwar commented on JBTM-3137: ------------------------------------- I did testing in my local system which has 8 CPU cores, so I observed different result in CI system, since that system has 24 cores. > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.redhat.com/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3137?page=com.atlassian.jira.plugin... ] Mayank Kunwar commented on JBTM-3137: ------------------------------------- For this issue I made two changes: 1. There is a article for making the benchmark more effective and using JMH in proper manner (best practices) so that we could get more accurate performance. Here is the article link https://www.researchgate.net/publication/333825812_What's_Wrong_With_My_Benchmark_Results_Studying_Bad_Practices_in_JMH_Benchmarks Under this article, the author has provided a plugin for finding JMH related bugs. So we have to import this plugin on top of Spotbug plugin in IDE. So, once I imported JMH spotbug plugin and applied it to the performance repo, it was reporting some bugs related to JMH usage. We were not using JMH effectively. So I fixed all these bugs, reported by the mentioned plugin. Under the article that I mentioned above, it says that we have to restrict JVM optimization by using Blackhole (from JMH), so that we could evaluate performance of the Tests more effectively. 2. I did an experiment with a simple program, in order to evaluate more appropriate JMH argument, which will provide us with more accurate performance results. Maybe these values can be tuned, further more effectively. I think tuning these values is a tricky part. Here is a simple program. @Benchmark public boolean evaluateJMHParam(Blackhole bh) { for(int i=0; i<10;i++){ bh.consume(Math.log(i)); } return true; } After iterating the JMH arguments, five times each, for different combinations of JMH arguments, got to a conclusion to use *JMH Arguments* as : -t $i -r 30 -f 3 -wi 5 -i 5 t - thread count r - measurement run time f - fork wi - warmup iterations i - iterations In the above JMH arguments: the $i that is thread count, that will vary. Values for $i will be [1, 24, 240, 1600] > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.redhat.com/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3233) Port the JTA recovery quickstart to run with the Quarkus Narayana JTA extension

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3233?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3233: ---------------------------------------- I created a PoC for this work in my own repo (https://github.com/mmusgrov/quickstart-1/tree/jms/quarkus/jms). And there is an ongoing discussion about what kind of functionality we want (see the thread on the quarkus-dev list with the subject line "Last resource optimisation for JMS QPid". > Port the JTA recovery quickstart to run with the Quarkus Narayana JTA extension > ------------------------------------------------------------------------------- > > Key: JBTM-3233 > URL: https://issues.redhat.com/browse/JBTM-3233 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Quickstarts > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The [JTA recovery quickstart|https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/re...] with maven artefact id: org.jboss.narayana.quickstart.jta:recovery looks like it should run fine with the [Quarkus Narayana JTA extension|https://github.com/quarkusio/quarkus/tree/master/extensions/nar...]. > This task is to check what we need to do with the quickstart to run it with the extension. Maybe include it as one of the [Quarkus quickstart examples|https://github.com/quarkusio/quarkus-quickstarts]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3201) Prevent linkage error in SimpleIsolatedServers

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3201?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3201: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.10.0.Final Assignee: Thomas Jenkinson Resolution: Done I found this should be resolved thus resolving. > Prevent linkage error in SimpleIsolatedServers > ---------------------------------------------- > > Key: JBTM-3201 > URL: https://issues.redhat.com/browse/JBTM-3201 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > Fix For: 5.10.0.Final > > Attachments: com.arjuna.ats.jta.distributed.SimpleIsolatedServers-output.txt > > > The class can be loaded by the test classloader multiple times. It looks to be missing synchronization. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3255) Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use`

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3255?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3255: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13009 > Intermittent failure of CI AS_TESTS in multinode module with error `The port 10090 is already in use` > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-3255 > URL: https://issues.redhat.com/browse/JBTM-3255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Attachments: JBTM-3255-occupied-port-10990.zip > > > There could be observed intermittent failures of AS_TESTS in Narayana CI where the job fails with error {{The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090.}}[1] > The reason seems to be there is probably unfinished application server running from the prior testsuite module. > Here we talk about the second server which starts the port `10090` as the management port. > The arquillian starts the `multinode` module and the first test fails with error that the WildFly can't be started as port can't be bound. > It could be that there is either some process occupying the port `10090` on the Linux machine. > But the more probable is that the prior test which is in `clustering` as `org.jboss.as.test.clustering.cluster.ejb2.stateful.failover.RemoteEJBClientStatefulBeanFailoverTestCase` was not finished properly. > The log files does not show any particular trouble though. > [1] > {code} > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.818 s <<< FAILURE! - in org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase > [ERROR] org.jboss.as.test.multinode.clientinterceptor.multiple.MultipleClientInterceptorTestCase Time elapsed: 3.818 s <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: > The port 10090 is already in use. It means that either the server might be already running or there is another process using port 10090. > Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server. > Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port. > To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.failDueToRunning(ManagedDeployableContainer.java:323) > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:81) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:123) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2020