[JBoss JIRA] (WFCORE-3054) (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3054?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3054:
------------------------------------------
Reopening as the related JBEAP was reopened. I believe I resolved this prematurely.
> (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3054
> URL: https://issues.jboss.org/browse/WFCORE-3054
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> *Description of problem:*
> Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
> *Steps to Reproduce:*
> # configure https
> # loop, more clients in parralel:
> #* ./jboss-cli.sh -c ":read-attribute(name=server-state)" -Djavax.net.ssl.trustStore=... -Djavax.net.ssl.trustStorePassword=...
> *How reproducible:*
> Intermittently
> *Actual results:*
> Thread dump is attached
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3054) (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3054?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3054:
-------------------------------------
Fix Version/s: (was: 3.0.0.Beta29)
> (7.1.0) Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3054
> URL: https://issues.jboss.org/browse/WFCORE-3054
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> *Description of problem:*
> Connection timeout CLI issue on HTTPS, if more cli clients are used in a loop.
> *Steps to Reproduce:*
> # configure https
> # loop, more clients in parralel:
> #* ./jboss-cli.sh -c ":read-attribute(name=server-state)" -Djavax.net.ssl.trustStore=... -Djavax.net.ssl.trustStorePassword=...
> *How reproducible:*
> Intermittently
> *Actual results:*
> Thread dump is attached
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2207) Use of AUTH does result in a SecurityException if another client does not use AUTH
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2207:
---------------------------
Attachment: JGroupsAuthExample.java
> Use of AUTH does result in a SecurityException if another client does not use AUTH
> ----------------------------------------------------------------------------------
>
> Key: JGRP-2207
> URL: https://issues.jboss.org/browse/JGRP-2207
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: JGroupsAuthExample.java, JGroupsAuthExample.java
>
>
> If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2207) Use of AUTH does result in a SecurityException if another client does not use AUTH
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2207?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2207:
--------------------------------
If you set {{authenticate_coord}} to false, then you get the desired outcome, see the attached modified program.
IMO, a rogue member not being able to join a cluster is as good as receiving a security exception.
Note that {{AUTH}} may not be necessary with the new {{ASYM_ENCRYPT}} and {{SSL_KEY_EXCHANGE}} protocols, as the latter includes peer authentication.
[1] http://www.jgroups.org/manual4/index.html#ENCRYPT
> Use of AUTH does result in a SecurityException if another client does not use AUTH
> ----------------------------------------------------------------------------------
>
> Key: JGRP-2207
> URL: https://issues.jboss.org/browse/JGRP-2207
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.4
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: JGroupsAuthExample.java
>
>
> If there are two members in a cluster, one with AUTH configured and started first, so it can become the coordinator and a second without AUTH, the documentation implies that the second should receive a SecurityException. Instead, it creates it's own cluster. This works as expected if the second member uses AUTH, but has a different SecurityToken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1321) Possible NPE in LdapSecurityRealm.closeContext
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1321?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1321:
----------------------------
Description:
There is missing null check in LdapSecurityRealm.closeContext [1] which can result to NPE.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/001e69270ddb6d27...
{code}
ERROR [io.undertow.request] (default task-58) UT005023: Exception handling request to /LdapPerformance/protected/SimpleSecuredServlet: java.lang.NullPointerException
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.closeContext(LdapSecurityRealm.java:221)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$500(LdapSecurityRealm.java:102)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAttributes(LdapSecurityRealm.java:543)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAuthorizationIdentity(LdapSecurityRealm.java:501)
{code}
was:
There is missing null check in LdapSecurityRealm.closeContext [1] which can result to NPE.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/001e69270ddb6d27...
> Possible NPE in LdapSecurityRealm.closeContext
> ----------------------------------------------
>
> Key: ELY-1321
> URL: https://issues.jboss.org/browse/ELY-1321
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.CR4
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> There is missing null check in LdapSecurityRealm.closeContext [1] which can result to NPE.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/001e69270ddb6d27...
> {code}
> ERROR [io.undertow.request] (default task-58) UT005023: Exception handling request to /LdapPerformance/protected/SimpleSecuredServlet: java.lang.NullPointerException
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.closeContext(LdapSecurityRealm.java:221)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$500(LdapSecurityRealm.java:102)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAttributes(LdapSecurityRealm.java:543)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getAuthorizationIdentity(LdapSecurityRealm.java:501)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1322) Found multiple secret keys sharing same CKA_LABEL
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-1322?page=com.atlassian.jira.plugin.s... ]
Peter Skopek moved JBEAP-12627 to ELY-1322:
-------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1322 (was: JBEAP-12627)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Credential Store
(was: Security)
Affects Version/s: 1.1.0.CR3
(was: 7.1.0.ER1)
> Found multiple secret keys sharing same CKA_LABEL
> -------------------------------------------------
>
> Key: ELY-1322
> URL: https://issues.jboss.org/browse/ELY-1322
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.CR3
> Reporter: Peter Skopek
> Assignee: Peter Skopek
> Priority: Blocker
> Labels: eap7.1-rfe-failure
>
> When multiple PKCS11 keystores are configured in domain [1][2]. And PKCS11 store contains secret key. Then this exception is thrown on startup intermittently (but very often, cca 50%).
> {code:server.log}
> [Host Controller] 10:15:05,526 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.key-store.oneWayKS: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.oneWayKS: WFLYELY00004: Unable to start the service.
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:146)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: java.io.IOException: load failed
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.security.keystore.AtomicLoadKeyStoreSpi.engineLoad(AtomicLoadKeyStoreSpi.java:55)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:137)
> [Host Controller] ... 5 more
> [Host Controller] Caused by: java.security.KeyStoreException: invalid KeyStore state: found multiple secret keys sharing same CKA_LABEL [my-key]
> [Host Controller] at sun.security.pkcs11.P11KeyStore.mapLabels(P11KeyStore.java:2408)
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:755)
> [Host Controller] ... 9 more
> {code}
> Storing secret key into PKCS11 store is necessary for FIPS Credential store implementation.
> {code:java|title=sun.security.pkcs11.P11KeyStore.java}
> for (long handle : handles) {
> attrs = new CK_ATTRIBUTE[] { new CK_ATTRIBUTE(CKA_LABEL) };
> token.p11.C_GetAttributeValue(session.id(), handle, attrs);
> if (attrs[0].pValue != null) {
> // there is a CKA_LABEL
> String cka_label = new String(attrs[0].getCharArray());
> if (sKeyMap.get(cka_label) == null) {
> sKeyMap.put(cka_label, new AliasInfo(cka_label));
> } else {
> throw new KeyStoreException("invalid KeyStore state: " +
> "found multiple secret keys sharing same " +
> "CKA_LABEL [" +
> cka_label +
> "]");
> }
> }
> }
> {code}
> It seems to me problem will be PKCS11 store (system wide) is loaded concurrently multiple times and therefore sometimes JDK check triggers false positive alarm [3].
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [2] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [3] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9209) Patch needed for WF 10.1.0.Final for CVE-2016-4970
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9209?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-9209:
-----------------------------------
Netty that is part of WildFly is not used for web server,
is there as dependency to artemis messaging component.
As such it is isolated to uses within artemis and not directly exposed to the world.
Our webserver component is Undertow.
For CVEs, the Red Hat security advisory is the main place to look, from there, you can find links to various issue trackers also to WildFly if CVE affects it.
Btw, how do 3rd party scanners flag this problem in WildFly? Via testing the exploit on https port or by just scanning the jars of the server and looking into versions of components?
> Patch needed for WF 10.1.0.Final for CVE-2016-4970
> --------------------------------------------------
>
> Key: WFLY-9209
> URL: https://issues.jboss.org/browse/WFLY-9209
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: John Hovell
> Assignee: Jason Greene
>
> Several 3rd party security scanners we use flag Wildfly 10.1.0.Final as containing the following DoS vulnerability:
> https://nvd.nist.gov/vuln/detail/CVE-2016-4970
> I have found a Redhat errata and bugzilla but neither references Wildfly specifically nor does CVE-2016-4970 turn up on a search here in Jira.
> https://access.redhat.com/security/cve/cve-2016-4970
> https://bugzilla.redhat.com/show_bug.cgi?id=1343616
> I am trying to understand if Wildfly team believes WF 10.1.0 is vulnerable and if so if it should be patched. I understand that WF 11 has an upgraded version of Netty which is not vulnerable to this CVE, but it is still in beta and security patches shouldn't need a major version upgrade.
> I am also trying to understand the official channel that the Wildfly project uses to track security errata as a search for "CVE" here only turns up ~3 other issues. Are the above Redhat links the place to look? And if so should Wildfly be marked as not affected, or why do they only refer to very very old versions of JBoss? I'd still be confused however how WF wouldn't be affected as it seems to contain wildfly/modules/system/layers/base/io/netty/main/netty-all-4.0.33.Final.jar which does not appear to be back-ported with a fix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3070) Found multiple secret keys sharing same CKA_LABEL
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3070?page=com.atlassian.jira.plugi... ]
Peter Skopek reopened WFCORE-3070:
----------------------------------
Reopening as error still occures in ER3 [1]
Looking into fix, synchronization is addressed in ProviderKeyManagerService.java and ProviderTrustManagerService.java, which fix legacy configuration (SSLMasterSlaveTwoWayTestCase). I can confirm I don't see failing SSLMasterSlaveTwoWayTestCase in ER3.
But same error occures also in Elytron configuration (SSLMasterSlaveTwoWayElytronTestCase). IMHO, similar synchronization should be added into org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:137), which occures in reported error stacktrace.
[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-...
> Found multiple secret keys sharing same CKA_LABEL
> -------------------------------------------------
>
> Key: WFCORE-3070
> URL: https://issues.jboss.org/browse/WFCORE-3070
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Peter Skopek
> Assignee: Peter Skopek
> Priority: Blocker
> Labels: eap7.1-rfe-failure
> Fix For: 3.0.0.Beta29
>
>
> When multiple PKCS11 keystores are configured in domain [1][2]. And PKCS11 store contains secret key. Then this exception is thrown on startup intermittently (but very often, cca 50%).
> {code:server.log}
> [Host Controller] 10:15:05,526 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.key-store.oneWayKS: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.oneWayKS: WFLYELY00004: Unable to start the service.
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:146)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> [Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: java.io.IOException: load failed
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.security.keystore.AtomicLoadKeyStoreSpi.engineLoad(AtomicLoadKeyStoreSpi.java:55)
> [Host Controller] at java.security.KeyStore.load(KeyStore.java:1445)
> [Host Controller] at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:137)
> [Host Controller] ... 5 more
> [Host Controller] Caused by: java.security.KeyStoreException: invalid KeyStore state: found multiple secret keys sharing same CKA_LABEL [my-key]
> [Host Controller] at sun.security.pkcs11.P11KeyStore.mapLabels(P11KeyStore.java:2408)
> [Host Controller] at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:755)
> [Host Controller] ... 9 more
> {code}
> Storing secret key into PKCS11 store is necessary for FIPS Credential store implementation.
> {code:java|title=sun.security.pkcs11.P11KeyStore.java}
> for (long handle : handles) {
> attrs = new CK_ATTRIBUTE[] { new CK_ATTRIBUTE(CKA_LABEL) };
> token.p11.C_GetAttributeValue(session.id(), handle, attrs);
> if (attrs[0].pValue != null) {
> // there is a CKA_LABEL
> String cka_label = new String(attrs[0].getCharArray());
> if (sKeyMap.get(cka_label) == null) {
> sKeyMap.put(cka_label, new AliasInfo(cka_label));
> } else {
> throw new KeyStoreException("invalid KeyStore state: " +
> "found multiple secret keys sharing same " +
> "CKA_LABEL [" +
> cka_label +
> "]");
> }
> }
> }
> {code}
> It seems to me problem will be PKCS11 store (system wide) is loaded concurrently multiple times and therefore sometimes JDK check triggers false positive alarm [3].
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [2] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-security/blob/...
> [3] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9210) XSiteSimpleTestCase doesn't work with different node0 and node1
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-9210?page=com.atlassian.jira.plugin.... ]
Marek Kopecký moved JBEAP-12626 to WFLY-9210:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9210 (was: JBEAP-12626)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
Test Suite
(was: Clustering)
(was: Test Suite)
Affects Version/s: 11.0.0.Beta1
(was: 7.1.0.ER3)
> XSiteSimpleTestCase doesn't work with different node0 and node1
> ---------------------------------------------------------------
>
> Key: WFLY-9210
> URL: https://issues.jboss.org/browse/WFLY-9210
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> *Description of problem:*
> XSiteSimpleTestCase is design to use node0, node1, node2 and node3. If all these node addresses are set to the same real address (like 127.0.0.1), test pass. Test pass also if these 4 addresses are different. But test fail, if only two addresses are set.
> * Test fail if node0==node2 && node1==node3 && node0!= node1
> * Test pass if node0==node1 && node2==node3 && node0!=node2. But all other tests in TS needs to have different node0 and node1. And XSiteSimpleTestCase is the only one testcase in EAP TS, that needs 4 addresses. So there is no way to run TS with two different IP addresses with passing XSiteSimpleTestCase.
> This is explained by [~rhusar] [here|https://issues.jboss.org/browse/WFLY-5239?focusedCommentId=13304413&...]
> I suggest to
> * keep current default behaviour
> * add new profile, that allows to run XSiteSimpleTestCase with two different IP addresses.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd testsuite/integration/clustering
> # mvn clean install -Dmaven.test.failure.ignore=true -Djboss.dist=$JBOSS_DIST -Dtest=XSiteSimpleTestCase \
> -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> *Actual results:*
> StackTrace:
> {noformat}
> Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 47.186 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
> testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase) Time elapsed: 42.766 sec <<< FAILURE!
> java.lang.AssertionError: expected:<200> but was:<500>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutRelayedToBackups(XSiteSimpleTestCase.java:169)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> This jira doesn't fix JBEAP-11086
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months