[JBoss JIRA] (WFCORE-1507) Expose features currently provided by ModelController via capabilities usable by extensions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1507:
-------------------------------------
Summary: Expose features currently provided by ModelController via capabilities usable by extensions (was: Expose the ModelController via a capability)
> Expose features currently provided by ModelController via capabilities usable by extensions
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-1507
> URL: https://issues.jboss.org/browse/WFCORE-1507
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> A server installs ServerService while an HC installs DomainModelControllerService, under different service names but both of which implement Service<ModelController>. To make it easier for subsystems that want ModelController access to work on both a server and an HC, we should create a capability with service type ModelController and have both processes use it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-7539) WebSocketTestCase fails with security manager - disable test
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7539?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-7539:
-----------------------------------
Fix Version/s: 10.2.0.Final
> WebSocketTestCase fails with security manager - disable test
> ------------------------------------------------------------
>
> Key: WFLY-7539
> URL: https://issues.jboss.org/browse/WFLY-7539
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> With the core 3.0.0.Alpha12 upgrade we see failures in the WebSocketTestCase when run with the security manager enabled.
> $mvn clean install -pl testsuite/integration/web/ -Dsecurity.manager=true
> For now I am adding a
> {code}
> Assume.assumeTrue(System.getSecurityManager() == null);
> {code}
> to skip this test when running with a security manager enabled. The failure when the test is run with a security manager is
> {code}
> testWebSocket(org.jboss.as.test.integration.web.websocket.WebSocketTestCase) Time elapsed: 0.227 sec <<< ERROR!
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/websocket.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.websocket.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkListen(SecurityManager.java:1131)
> at org.wildfly.security.manager.WildFlySecurityManager.checkListen(WildFlySecurityManager.java:392)
> at sun.nio.ch.SocketChannelImpl.bind(SocketChannelImpl.java:582)
> at sun.nio.ch.SocketAdaptor.bind(SocketAdaptor.java:135)
> at org.xnio.nio.WorkerThread.openTcpStreamConnection(WorkerThread.java:263)
> at org.xnio.XnioIoThread.openStreamConnection(XnioIoThread.java:237)
> at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:342)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165)
> at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:129)
> at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connectImpl(WebSocketClient.java:323)
> at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connect(WebSocketClient.java:211)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:463)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:457)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServer(ServerWebSocketContainer.java:211)
> at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testWebSocket(WebSocketTestCase.java:52)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1958:
------------------------------------------
PR #2218 is merged so no tests are ignored with reference to this now.
> Clean up testsuite Elytron registration
> ---------------------------------------
>
> Key: WFCORE-1958
> URL: https://issues.jboss.org/browse/WFCORE-1958
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta7
>
>
> In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them..
> Also re-enable the following test case: -
> * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-987) Confusion in method with(AuthenticationContext other) in AuthenticationContext
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-987?page=com.atlassian.jira.plugin.sy... ]
David Lloyd reassigned ELY-987:
-------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> Confusion in method with(AuthenticationContext other) in AuthenticationContext
> ------------------------------------------------------------------------------
>
> Key: ELY-987
> URL: https://issues.jboss.org/browse/ELY-987
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta28
> Reporter: Ondrej Lukas
> Assignee: David Lloyd
> Priority: Critical
>
> org.wildfly.security.auth.client.AuthenticationContext includes method {{AuthenticationContext with(AuthenticationContext other)}} which creates new AuthenticationContext which includes rules and configuration and SSL context of given AuthenticationContext other.
> However, in case when {{with}} method is used with index and another AuthenticationContext, then it includes only rules and configuration (SSL context is not used). There is also method {{withSsl}} which includes rules and SSL context, but no configuration.
> I see three problems here:
> * there is different behavior between {{with(AuthenticationContext other)}} and {{with(int idx, AuthenticationContext other)}} - first includes also SSL context
> * javadoc for with(AuthenticationContext other) does not describe that SSL context from given {{AuthenticationContext other}} is also used.
> * there is not able to include both configuration and SSL context into any AuthenticationContext on some position based on index
> I report this as critical because it is part of public API - it should stay backward compatible once it will be released.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-991) SASL Digest client handles callbacks incorrectly
by David Lloyd (JIRA)
David Lloyd created ELY-991:
-------------------------------
Summary: SASL Digest client handles callbacks incorrectly
Key: ELY-991
URL: https://issues.jboss.org/browse/ELY-991
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Mechanisms, SASL
Reporter: David Lloyd
Right now the SASL digest client handles callbacks like this:
* If a realm choice is available use RealmChoiceCallback to get it, and fail if it is not supported
* Try to use RealmCallback+NameCallback+CredentialCallback (with digest password)
* Try to use RealmCallback+NameCallback+CredentialCallback (with two-way password)
* Try to use RealmCallback+NameCallback+PasswordCallback
This is a problem because RealmChoiceCallback should not be required, and if it was supported, RealmCallback is not needed. It's basically OK to retry realm selection and name selection if the credential was unsupported.
The logic should probably be more like this:
* Try to use <a realm callback>+NameCallback+CredentialCallback (with digest password)
** First try with RealmChoiceCallback if there is a choice
** Then try with RealmCallback if RealmChoiceCallback is unsupported
** If there is no default realm, fail
** Otherwise try with no realm callback and use the default realm
* Try to use <a realm callback>+NameCallback+CredentialCallback (with two-way password)
** First try with RealmChoiceCallback if it was not eliminated above and there is a choice
** Then try RealmCallback if it was not eliminated above
** If there is no default realm, fail
** Otherwise try with no realm callback and use the default realm
* Try to use <a realm callback>+NameCallback+PasswordCallback
** First try with RealmChoiceCallback if it was not eliminated above and there is a choice
** Then try RealmCallback if it was not eliminated above
** If there is no default realm, fail
** Otherwise try with no realm callback and use the default realm
This way we don't retry callbacks that don't work, and we don't fail if RealmCallback is not supported. If no user name or credential is given, then the attempt should be considered a failure and the next credential tried without eliminating any realm callbacks. If no realm is given then the attempt should be a failure without trying other realm callback options, because the callback is supported but there was no realm given (which is a programming error).
If a user name or realm is given in an earlier stage, it should stay as the default for later stages.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
by Peter Nalyvayko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Peter Nalyvayko commented on WFCORE-1705:
-----------------------------------------
Seems that some of the classes in that namespace are not portable across different JVMs, so decided to implement the missing functionality (OCSP checking) instead of relying on types from provider/certpath. Since this isn't an issue any longer, I feel I should close the issue.
> A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-1705) A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
by Peter Nalyvayko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1705?page=com.atlassian.jira.plugi... ]
Peter Nalyvayko closed WFCORE-1705.
-----------------------------------
Resolution: Won't Do
> A system dependency path "sun/security/provider/certpath" is missing from wildfly's module.xml
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1705
> URL: https://issues.jboss.org/browse/WFCORE-1705
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 2.2.0.Final
> Reporter: Peter Nalyvayko
> Assignee: David Lloyd
> Labels: jboss
>
> There is a system dependency path "sun/security/provider/certpath" missing from modules\system\layers\base\sun\jdk\main\module.xml. This is causing class def not found exception when attempting to create an instance of a class from that namespace. The module contents (abbreviated) are shown below. Notice that the path to "sun/security/provider/certpath" is not listed in there:
> {{<module xmlns="urn:jboss:module:1.3" name="sun.jdk">
> <resources>
> <!-- currently jboss modules has not way of importing services from
> classes.jar so we duplicate them here -->
> <resource-root path="service-loader-resources"/>
> </resources>
> <dependencies>
> <module name="sun.scripting" export="true"/>
> <system export="true">
> <paths>
> ...
> <path name="sun/security/action"/>
> <path name="sun/security/pkcs"/>
> <path name="sun/security/x509"/>
> <path name="sun/security"/>
> <path name="sun/security/util"/>
> <path name="sun/security/krb5"/>
> <path name="sun/security/krb5/internal"/>
> <path name="sun/security/pkcs11"/>
> <path name="sun/security/provider"/>
> ...
> </paths>
> <exports>
> <include-set>
> <path name="META-INF/services"/>
> </include-set>
> </exports>
> </system>
> </dependencies>
> </module>
> }}Manually adding the missing system dependency path fixes the issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-2453) Expose statistics configuration attribute per JGroups protocol
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2453?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-2453:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Expose statistics configuration attribute per JGroups protocol
> --------------------------------------------------------------
>
> Key: WFLY-2453
> URL: https://issues.jboss.org/browse/WFLY-2453
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
>
> By default, every JGroups protocol gathers statistics. Currently, this can be disabled per protocol via:
> <property name="stats">false</property>
> This is a bit cumbersome. Also, a standard property like this should be 1st class attribute of the <protocol/> element.
> e.g..
> <protocol type="..." statistics-enabled="false"/>
> We may also want to add the ability to disable statistics per stack, so the user does not have to explicitly disable it in every protocol. That way, to enable statistics for a single protocol, one could use:
> <stack name="udp" statistics-enabled="false"><!-- Disables collection of statistics for all protocols -->
> <transport type="UDP" statistics-enabled="true"/><!-- Enables collection of statistics for just this protocol -->
> ...
> </stack>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-8234) RemoteAsyncInvocationTestCase fails with Elytron profile in AS TS
by Yeray Borges Santana (JIRA)
[ https://issues.jboss.org/browse/WFLY-8234?page=com.atlassian.jira.plugin.... ]
Yeray Borges Santana commented on WFLY-8234:
--------------------------------------------
I cannot reproduce it with current wildfly master branch
{code}
------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.375 sec - in org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase
Results :
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27.568 s
[INFO] Finished at: 2017-03-03T18:43:35+00:00
[INFO] Final Memory: 113M/656M
[INFO] ------------------------------------------------------------------------
Java version: 1.8.0_121, vendor: Oracle Corporation
OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
git rev-parse HEAD
1c270e9bcf3bcb7e4b711c8bc7a4f627ccfb7fe0
{code}
> RemoteAsyncInvocationTestCase fails with Elytron profile in AS TS
> -----------------------------------------------------------------
>
> Key: WFLY-8234
> URL: https://issues.jboss.org/browse/WFLY-8234
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Reporter: Josef Cacek
>
> The {{RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue}} test fails on {{NullPointerException}} when executed with Elytron profile in AS TS.
> {code}
> cd testsuite/integration/basic
> mvn clean test -Dtest=RemoteAsyncInvocationTestCase -Delytron
> ...
> Tests in error:
> RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue:97 » NullPointer
> Tests run: 4, Failures: 0, Errors: 1, Skipped: 0
> {code}
> Full stack trace.
> {code}
> java.lang.reflect.InvocationTargetException
> 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.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 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.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.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> 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.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.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
> 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 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 sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1512)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:731)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:277)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 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)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1.processInvocation(AsyncFutureInterceptorFactory.java:85)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextStorageInterceptor.processInvocation(LogDiagnosticContextStorageInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:74)
> at org.jboss.as.test.integration.ejb.remote.async.LocalInterface$$$view2.passByReference(Unknown Source)
> at org.jboss.as.test.integration.ejb.remote.async.RemoteAsyncInvocationTestCase.testLocalAsyncInvocationByValue(RemoteAsyncInvocationTestCase.java:97)
> ... 144 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months