[JBoss JIRA] (WFLY-7665) Write attribute operation for Elytron ldap-key-store throws NPE
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7665?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7665:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Write attribute operation for Elytron ldap-key-store throws NPE
> ---------------------------------------------------------------
>
> Key: WFLY-7665
> URL: https://issues.jboss.org/browse/WFLY-7665
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
> Fix For: 11.0.0.Alpha1
>
>
> In case when CLI write-attribute operation is called for {{ldap-key-store}} then it results to NullPointerException.
> Exception occurs in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 7) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-key-store" => "ldapKeyStore")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.elytron.LdapKeyStoreDefinition$WriteAttributeHandler.getParentServiceName(LdapKeyStoreDefinition.java:359)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:57)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7574) Elytron "expressions-allowed" => true attributes
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7574?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7574:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Elytron "expressions-allowed" => true attributes
> ------------------------------------------------
>
> Key: WFLY-7574
> URL: https://issues.jboss.org/browse/WFLY-7574
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Fix For: 11.0.0.Alpha1
>
>
> Please review these usage of "expressions-allowed" => true
> * class names and module names
> {code}
> /custom-role-mapper/module
> /custom-role-mapper/class-name
> /constant-permission-mapper/module
> /constant-permission-mapper/class-name
> /simple-permission-mapper/permission-mappings/module
> /simple-permission-mapper/permission-mappings/class-name
> /custom-permission-mapper/module
> /custom-permission-mapper/class-name
> /custom-name-rewriter/module
> /custom-name-rewriter/class-name
> /custom-principal-decoder/module
> /custom-principal-decoder/class-name
> /custom-realm-mapper/module
> /custom-realm-mapper/class-name
> /service-loader-http-server-mechanism-factory/module
> /service-loader-sasl-server-factory/module
> /custom-modifiable-realm/module
> /custom-modifiable-realm/class-name
> /custom-credential-security-factory/module
> /custom-credential-security-factory/class-name
> /custom-role-decoder/module
> /custom-role-decoder/class-name
> /custom-realm/module
> /custom-realm/class-name
> {code}
> Brian: "Traditionally we also don't allow expressions on attributes whose values are classnames or module names
> TBH there is no great reason for that, beyond a feeling that it will allow greater flexibility for future changes at little practical cost
> but it's what we've done and we might as well stick to it"
> * referencing another services
> {code}
> /sasl-authentication-factory/mechanism-configurations/mechanism-realm-configurations
> /http-authentication-factory/mechanism-configurations/mechanism-realm-configurations
> /ldap-key-store/dir-context
> /server-ssl-context/provider-loader
> /client-ssl-context/provider-loader
> /filtering-key-store/key-store
> /dir-context/ssl-context
> /ldap-realm/dir-context
> /trust-managers/key-store
> /trust-managers/provider-loader
> /key-managers/key-store
> /key-managers/provider-loader
> /credential-store/relative-to
> /credential-store/provider-loader
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7574) Elytron "expressions-allowed" => true attributes
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7574?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7574:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Elytron "expressions-allowed" => true attributes
> ------------------------------------------------
>
> Key: WFLY-7574
> URL: https://issues.jboss.org/browse/WFLY-7574
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Fix For: 11.0.0.Alpha1
>
>
> Please review these usage of "expressions-allowed" => true
> * class names and module names
> {code}
> /custom-role-mapper/module
> /custom-role-mapper/class-name
> /constant-permission-mapper/module
> /constant-permission-mapper/class-name
> /simple-permission-mapper/permission-mappings/module
> /simple-permission-mapper/permission-mappings/class-name
> /custom-permission-mapper/module
> /custom-permission-mapper/class-name
> /custom-name-rewriter/module
> /custom-name-rewriter/class-name
> /custom-principal-decoder/module
> /custom-principal-decoder/class-name
> /custom-realm-mapper/module
> /custom-realm-mapper/class-name
> /service-loader-http-server-mechanism-factory/module
> /service-loader-sasl-server-factory/module
> /custom-modifiable-realm/module
> /custom-modifiable-realm/class-name
> /custom-credential-security-factory/module
> /custom-credential-security-factory/class-name
> /custom-role-decoder/module
> /custom-role-decoder/class-name
> /custom-realm/module
> /custom-realm/class-name
> {code}
> Brian: "Traditionally we also don't allow expressions on attributes whose values are classnames or module names
> TBH there is no great reason for that, beyond a feeling that it will allow greater flexibility for future changes at little practical cost
> but it's what we've done and we might as well stick to it"
> * referencing another services
> {code}
> /sasl-authentication-factory/mechanism-configurations/mechanism-realm-configurations
> /http-authentication-factory/mechanism-configurations/mechanism-realm-configurations
> /ldap-key-store/dir-context
> /server-ssl-context/provider-loader
> /client-ssl-context/provider-loader
> /filtering-key-store/key-store
> /dir-context/ssl-context
> /ldap-realm/dir-context
> /trust-managers/key-store
> /trust-managers/provider-loader
> /key-managers/key-store
> /key-managers/provider-loader
> /credential-store/relative-to
> /credential-store/provider-loader
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7810) Artemis hangs during failback in remote JCA scenario
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7810?page=com.atlassian.jira.plugin.... ]
Kabir Khan edited comment on WFLY-7810 at 12/16/16 12:18 PM:
-------------------------------------------------------------
https://github.com/jbossas/jboss-eap7/pull/1140 contains the full part and has been merged. The rest will come when Undertow is upgraded to 1.4.8
was (Author: kabirkhan):
https://github.com/jbossas/jboss-eap7/pull/1140
> Artemis hangs during failback in remote JCA scenario
> ----------------------------------------------------
>
> Key: WFLY-7810
> URL: https://issues.jboss.org/browse/WFLY-7810
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Remote JCA scenario:
> * There are 3 nodes
> * Node 1 and node 2 are Live-Backup pair (replicated HA)
> * Node 3 has MDB which remotely connects to node 1 and is able to do failover on node 2
> * During the test, node 1 is killed and started again
> Problem occurs when node 1 is started again. Servers are configured to do failback. When node 1 wants to become live again, something goes wrong with connection between node 1 and node 2. On node 1 I can see repeated WARN message \[1\]. Node 2 prints repeatedly WARN message \[2\].
> I can see the same issue also with 7.0.x. We haven't notice this error because the test didn't check state of servers after the failback.
> When I modify the test to not deploy MDB on node 3, the test passes without any unusual error. It seems the issue is related to this scenario.
> \[1\]
> {code}
> 09:59:09,197 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@26357508-1826618556)) AMQ222137: Unable to announce backup, retrying: ActiveMQConnec
> tionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:747) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:625) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:607) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.server.cluster.BackupManager$BackupConnector$1.run(BackupManager.java:246) [artemis-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) [artemis-commons-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
> {code}
> \[2\]
> {code}
> 10:00:19,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:29,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:39,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:49,246 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:59,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:09,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:19,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:29,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:39,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:49,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:59,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:02:09,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7810) Artemis hangs during failback in remote JCA scenario
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7810?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-7810:
----------------------------------
https://github.com/jbossas/jboss-eap7/pull/1140
> Artemis hangs during failback in remote JCA scenario
> ----------------------------------------------------
>
> Key: WFLY-7810
> URL: https://issues.jboss.org/browse/WFLY-7810
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Remote JCA scenario:
> * There are 3 nodes
> * Node 1 and node 2 are Live-Backup pair (replicated HA)
> * Node 3 has MDB which remotely connects to node 1 and is able to do failover on node 2
> * During the test, node 1 is killed and started again
> Problem occurs when node 1 is started again. Servers are configured to do failback. When node 1 wants to become live again, something goes wrong with connection between node 1 and node 2. On node 1 I can see repeated WARN message \[1\]. Node 2 prints repeatedly WARN message \[2\].
> I can see the same issue also with 7.0.x. We haven't notice this error because the test didn't check state of servers after the failback.
> When I modify the test to not deploy MDB on node 3, the test passes without any unusual error. It seems the issue is related to this scenario.
> \[1\]
> {code}
> 09:59:09,197 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@26357508-1826618556)) AMQ222137: Unable to announce backup, retrying: ActiveMQConnec
> tionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:747) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:625) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:607) [artemis-core-client-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.core.server.cluster.BackupManager$BackupConnector$1.run(BackupManager.java:246) [artemis-server-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) [artemis-commons-1.5.0.redhat-1.jar:1.5.0.redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
> {code}
> \[2\]
> {code}
> 10:00:19,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:29,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:39,245 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:49,246 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:00:59,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:09,247 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:19,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:29,248 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:39,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:49,249 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:01:59,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> 10:02:09,250 WARN [org.apache.activemq.artemis.core.client] (Thread-135) AMQ212042: Timed out waiting for packet to be flushed
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7814) Update XSD with deprecations from infinispan 4.1 model
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-7814:
------------------------------------
Summary: Update XSD with deprecations from infinispan 4.1 model
Key: WFLY-7814
URL: https://issues.jboss.org/browse/WFLY-7814
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Trivial
[~lthon]:
{quote}
Also, in the infinispan subsystem 4.1, attributes queue-flush-interval and queue-size are deprecated and ignored. This should be reflected in the new jboss-as-infinispan_4_1.xsd as well.
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months