[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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 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)
9 years, 2 months
[JBoss JIRA] (DROOLS-1462) not( null ) unary test not working
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1462:
-------------------------------------
Summary: not( null ) unary test not working
Key: DROOLS-1462
URL: https://issues.jboss.org/browse/DROOLS-1462
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.0.0.Beta6
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 7.0.0.Final
The engine is not properly creating the unary test ```not( null )``` and raising a NPE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2077) OutOfMemoryError: Metaspace after several client calls
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2077?page=com.atlassian.jira.plugi... ]
Tomaz Cerar resolved WFCORE-2077.
---------------------------------
Fix Version/s: 3.0.0.Beta5
Resolution: Done
I think it is safe to resolve this now.
If noting else, initial problems ware addressed.
If new ones are found, new jira should be opened.
> OutOfMemoryError: Metaspace after several client calls
> ------------------------------------------------------
>
> Key: WFCORE-2077
> URL: https://issues.jboss.org/browse/WFCORE-2077
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha13
> Reporter: Petr Kremensky
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 3.0.0.Beta5
>
>
> I saw some java.lang.OutOfMemoryError: Metaspace in our AS-Testsuite runs. Here is a really simple (and clumsy) reproducer for the leak.
> *repreduce*
> {noformat}
> # lower the metaspace size in jboss-eap-7.1/bin/standalone.conf to
> # -XX:MaxMetaspaceSize=64m
> # start standalone
> ./jboss-eap-7.1/bin/standalone.sh
> # run the following loop (any other mgmt operation should serve the same)
> for i in `seq 1 1000` ; do ./jboss-eap-7.1/bin/jboss-cli.sh -c :read-resource ; done
> # wait for OOM
> {noformat}
> {noformat}
> 14:24:29,629 WARN [org.jboss.modules] (MSC service thread 1-3) Failed to define class io.undertow.security.impl.SimpleNonceManager in Module "io.undertow.core:main" from local module loader @629f0666 (finder: local module finder @1bc6a36e (roots: /home/pkremens/workspace/jboss-eap-7.1/modules,/home/pkremens/workspace/jboss-eap-7.1/modules/system/layers/base)): java.lang.OutOfMemoryError: Metaspace
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:359)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:438)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:275)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:79)
> at org.jboss.modules.Module.loadModuleClass(Module.java:612)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:377)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:365)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> at org.jboss.as.domain.http.server.security.LogoutHandler.<init>(LogoutHandler.java:76)
> at org.jboss.as.domain.http.server.ManagementHttpServer.addLogoutHandler(ManagementHttpServer.java:316)
> at org.jboss.as.domain.http.server.ManagementHttpServer.setupOpenListener(ManagementHttpServer.java:395)
> at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:271)
> at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107)
> at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589)
> at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months