[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2167:
---------------------------
Fix Version/s: 4.0.3
(was: 4.0.2)
Priority: Minor (was: Major)
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0.3
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8595) Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-8595?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-8595:
-------------------------------------
You probably need to add the jboss-logmanager JAR to the {{-Xbootclasspath}}, {{-Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.4.Final}}. Assuming a standalone server here you'd need to modify the {{JBOSS_MODULES_SYSTEM_PKGS}} environment variable in the {{standalone.conf}} (or {{standalone.conf.bat}} for Windows) and add {{org.jboss.logmanager}}. You'll also need to make sure the {{-Djava.util.logging.manager=org.jboss.logmanager.LogManager}} is included in the {{JAVA_OPTS}}.
Other than that there is not much WildFly can actually do.
> Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8595
> URL: https://issues.jboss.org/browse/WFLY-8595
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Affects Versions: 10.1.0.Final
> Environment: * Wildfly 10.1
> * IBM JDK 8
> * YAJSW 11
> Reporter: will milspec
> Assignee: James Perkins
>
> *Upshot*
> Wildfly 10.1 fails to run when called from YAJSW (Yet Another Service Wrapper) on the IBM JDK.
> It fails because YAJSW instantiates/calls MemoryMXBean prior to running the wildfly classes.
> IBM's implementation of MemoryMXBean instantiates the Logging manager, i.e. class identified by -Djava.util.logging.manager.
> A "class/classloader" conflict exists for the logging manager. Because IBM JDK's MemoryMXBean "got to the log manager" first, wildfly presuppositions are undermined, i.e. the "system classloader" loaded the log manager, not the "jboss module classloader". A 'class identify check' (see below) fails.
> *More Details*
> This test returns false for Oracle JDK, true for IBM when run under yajsw. i.e. Under OracleJDK, LogManager.getLogManager() has a different classloader (the jboss module classoader ) than does the LogManager.class (system classloader)
> jboss-modules.git/src/main/java/org/jboss/modules/Main.java
> {{ final String logManagerName = getServiceName(bootClassLoader, "java.util.logging.LogMa
> nager");
> if (logManagerName != null) {
> System.setProperty("java.util.logging.manager", logManagerName);
> * if (LogManager.getLogManager().getClass() == LogManager.class) {
> * System.err.println("WARNING: Failed to load the specified log manager class " + logManagerName);
> } else {
> Module.setModuleLogger(new JDKModuleLogger());
> }
> }
> }}
> *Workaround Gets Farther but Undermines Presuppositions of App Server*
> If I add this jar to the Xbootclasspath/p, the "ibm system classes" loads org.jboss.logmanager.LogManager, but a downstream check in the jboss code throws an exception because the wrong classloader loaded org.jboss.logmanager.LogManager.
> *Steps to Reproduce*
> -Download IBM JDK
> -Download yajsw. Run its "genconfig" tool to generate a configration file
> -Start wildfly
> *Resource Xref*
> When I first came across this issue, I had trouble discerning "where the problem lay", i.e. in what source code. I posted on the ibm developer works, yajsw and wildfly forums.
> https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/
> ibm developer works forum:
> https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae...
> jboss developer forum:
> https://developer.jboss.org/thread/272840
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1086) CS tool, Command without any option must show help rather then error message about required options.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1086?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1086:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> CS tool, Command without any option must show help rather then error message about required options.
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-1086
> URL: https://issues.jboss.org/browse/ELY-1086
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Command without any option must show help rather then error message about required options.
> *How to reproduce:*
> {code}
> java -jar wildfly-elytron-tool.jar credential-store
> Exception encountered executing the command:
> org.apache.commons.cli.MissingOptionException: Missing required option: [-a Add new alias to the credential store, -r Remove alias from the credential store, -e Check if alias exists within the credential store, -v Display all aliases, -h Get help with usage of this command]
> at org.apache.commons.cli.DefaultParser.checkRequiredOptions(DefaultParser.java:199)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:130)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:81)
> at org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:120)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:74)
> {code}
> *Same for mask command*
> {code}
> java -jar wildfly-elytron-tool.jar mask
> Exception encountered executing the command:
> org.apache.commons.cli.MissingOptionException: Missing required option: [-x Secret to be encrypted, -h Get help with usage of this command]
> at org.apache.commons.cli.DefaultParser.checkRequiredOptions(DefaultParser.java:199)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:130)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:81)
> at org.wildfly.security.tool.MaskCommand.execute(MaskCommand.java:72)
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:74)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8595) Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
by will milspec (JIRA)
will milspec created WFLY-8595:
----------------------------------
Summary: Wildfly fails if wrapper class calls MemoryMXBean due to "logging manager" conflict (IBM JDK and YAJSW)
Key: WFLY-8595
URL: https://issues.jboss.org/browse/WFLY-8595
Project: WildFly
Issue Type: Feature Request
Components: Logging
Affects Versions: 10.1.0.Final
Environment: * Wildfly 10.1
* IBM JDK 8
* YAJSW 11
Reporter: will milspec
Assignee: James Perkins
*Upshot*
Wildfly 10.1 fails to run when called from YAJSW (Yet Another Service Wrapper) on the IBM JDK.
It fails because YAJSW instantiates/calls MemoryMXBean prior to running the wildfly classes.
IBM's implementation of MemoryMXBean instantiates the Logging manager, i.e. class identified by -Djava.util.logging.manager.
A "class/classloader" conflict exists for the logging manager. Because IBM JDK's MemoryMXBean "got to the log manager" first, wildfly presuppositions are undermined, i.e. the "system classloader" loaded the log manager, not the "jboss module classloader". A 'class identify check' (see below) fails.
*More Details*
This test returns false for Oracle JDK, true for IBM when run under yajsw. i.e. Under OracleJDK, LogManager.getLogManager() has a different classloader (the jboss module classoader ) than does the LogManager.class (system classloader)
jboss-modules.git/src/main/java/org/jboss/modules/Main.java
{{ final String logManagerName = getServiceName(bootClassLoader, "java.util.logging.LogMa
nager");
if (logManagerName != null) {
System.setProperty("java.util.logging.manager", logManagerName);
* if (LogManager.getLogManager().getClass() == LogManager.class) {
* System.err.println("WARNING: Failed to load the specified log manager class " + logManagerName);
} else {
Module.setModuleLogger(new JDKModuleLogger());
}
}
}}
*Workaround Gets Farther but Undermines Presuppositions of App Server*
If I add this jar to the Xbootclasspath/p, the "ibm system classes" loads org.jboss.logmanager.LogManager, but a downstream check in the jboss code throws an exception because the wrong classloader loaded org.jboss.logmanager.LogManager.
*Steps to Reproduce*
-Download IBM JDK
-Download yajsw. Run its "genconfig" tool to generate a configration file
-Start wildfly
*Resource Xref*
When I first came across this issue, I had trouble discerning "where the problem lay", i.e. in what source code. I posted on the ibm developer works, yajsw and wildfly forums.
https://sourceforge.net/p/yajsw/discussion/810311/thread/e730451b/
ibm developer works forum:
https://www.ibm.com/developerworks/community/forums/html/topic?id=8e9e4ae...
jboss developer forum:
https://developer.jboss.org/thread/272840
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2671) CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2671?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2671:
------------------------------------
Assignee: Darran Lofthouse (was: Yeray Borges)
> CLI Opertation 'load' for Elytron key-store does not correctly re-read keystore
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2671
> URL: https://issues.jboss.org/browse/WFCORE-2671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> When keystore (or cerficate in keystore) is changed during server runtime then CLI opertation {{load}} can be used for {{/subsystem=elytron/key-store=...}} to re-reading this keystore in server. However after calling this operation server still works with original keystore/certificate. Then CLI reads current keystore correctly, but in case when ssl-context which uses that key-store is used then original keystore is still used by server. Reload of server is required to correctly re-read the new keystore. See Steps to Reproduce for more details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8594) Loading custom infinispan cache store from custom module fails
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8594?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10402 to WFLY-8594:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8594 (was: JBEAP-10402)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> Loading custom infinispan cache store from custom module fails
> --------------------------------------------------------------
>
> Key: WFLY-8594
> URL: https://issues.jboss.org/browse/WFLY-8594
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Custom cache store allow a cache store to be loaded from a class. This is only really useful when the cache store implementation resides in the module specified by the cache. However, custom cache stores are currently only loaded from the infinispan subsystem module rather than the module specified by the cache.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1083) Elytron Client Configuration File does not allow to use truststore
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1083?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1083:
-------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Elytron Client Configuration File does not allow to use truststore
> ------------------------------------------------------------------
>
> Key: ELY-1083
> URL: https://issues.jboss.org/browse/ELY-1083
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.Beta34
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron Client Configuration File ({{wildfly-config.xml}}) does not allow to use or configure truststore. It seems there are not related truststore attributes and also {{org.wildfly.security.auth.client.ElytronXmlParser}} does not use {{setTrustManager()}} method.
> It means that following cannot be configured in Elytron Client Configuration File:
> * 1-way SSL where Elytron clients need to trust the certificate from server
> * 2-way SSL cannot be set between application server and Elytron Client
> We request blocker since this issue blocks RFE EAP7-567.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8379) TransactionScopedJMSContextTestCase fails with security manager
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8379?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka reassigned WFLY-8379:
-------------------------------------
Assignee: Ondra Chaloupka
> TransactionScopedJMSContextTestCase fails with security manager
> ---------------------------------------------------------------
>
> Key: WFLY-8379
> URL: https://issues.jboss.org/browse/WFLY-8379
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Ondra Chaloupka
>
> *org.jboss.as.test.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase#sendAndReceiveWithContext*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=TransactionScopedJMSContextTestCase -Dsecurity.manager}}
> {code}
> 14:33:57,124 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-5) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 14:33:57,124 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-4) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 14:33:57,125 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-2) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 14:33:57,125 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 14:33:57,126 SEVERE [org.glassfish.enterprise.concurrent] (EE-ManagedThreadFactory-default-Thread-3) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.transaction.TransactionPermission" "modifyUserTransactionAvailability")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "null")
> 14:34:28,356 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase.sendAndReceiveWithContext: java.lang.AssertionError: expected:<50> but was:<0>
> 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.integration.messaging.jms.context.transactionscoped.TransactionScopedJMSContextTestCase.sendAndReceiveWithContext(TransactionScopedJMSContextTestCase.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:287)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:124)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:58)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:249)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:150)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:264)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:831)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:813)
> 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:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1087) Elytron caching-realm backed by ldap-realm should evict or update the cache when a related role changes in LDAP
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1087?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-10399 to ELY-1087:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1087 (was: JBEAP-10399)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Realms
(was: Security)
Affects Version/s: 1.1.0.Beta37
(was: 7.1.0.DR16)
> Elytron caching-realm backed by ldap-realm should evict or update the cache when a related role changes in LDAP
> ---------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1087
> URL: https://issues.jboss.org/browse/ELY-1087
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta37
> Environment: LDAP: ApacheDS
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: caching, eap71_beta, ldap, ldap-realm, security-realm
>
> Elytron {{caching-realm}} backed by {{ldap-realm}} does not evict or update a cached identity when a role related to the identity is changed in LDAP, see steps to reproduce.
> This is against the following hard requirement of EAP7-542: _"Ability to listen for events fired by a modifiable realm in order to evict or update the cache accordingly."_ The ability is available but not used in this case. Hence the priority is set to {{Blocker}}. The issue blocks the RFE to be verified. The issue does not block test development for the RFE. The issue has been revealed by fixing JBEAP-8679.
> The eviction/updating works when user password is changed in LDAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months