June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6755: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/2962 (was: https://github.com/jbossas/jboss-as/pull/2962) > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved AS7-4876 to WFLY-6755: ---------------------------------------- Project: WildFly (was: Application Server 7) Key: WFLY-6755 (was: AS7-4876) Component/s: Clustering (was: Clustering) Affects Version/s: (was: 7.1.1.Final) (was: 7.1.2.Final (EAP)) Fix Version/s: 11.0.0.Alpha1 (was: EAP 6.1.0.Alpha (7.2.0.Final)) > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4876) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-4876?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar reopened AS7-4876: ------------------------------ That was never actually done, it was expected to be merged together with WFLY-258 work, which was never done. > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: AS7-4876 > URL: https://issues.jboss.org/browse/AS7-4876 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP) > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-112) Schemes "http" and "https" are problematic

by David Lloyd (JIRA)

David Lloyd created REMJMX-112: ---------------------------------- Summary: Schemes "http" and "https" are problematic Key: REMJMX-112 URL: https://issues.jboss.org/browse/REMJMX-112 Project: Remoting JMX Issue Type: Bug Reporter: David Lloyd Assignee: Darran Lofthouse Priority: Minor Converting the service URI scheme to "http" or "https" from "remote+http"/"http-remoting-jmx" and similar is problematic because the Remoting Endpoint will not support those schemes starting with 5.0, and those schemes will be (re)used for the purpose of proper HTTP or HTTP/2 driven invocation; it is possible or even likely that we will eventually have a true HTTP JMX transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Ingo Weiss edited comment on WFCORE-1606 at 6/22/16 7:15 AM: ------------------------------------------------------------- Am I wrong assuming the issue lies here, https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... ? was (Author: iweiss): Am I wrong assuming the issue lies here, https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Ingo Weiss (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Ingo Weiss commented on WFCORE-1606: ------------------------------------ Am I wrong assuming the issue lies here, https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6754) Bindings of most binding-types can not be created in naming subsystem configuration in Web Console

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-6754?page=com.atlassian.jira.plugin.... ] Tomas Hofman moved JBEAP-5102 to WFLY-6754: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6754 (was: JBEAP-5102) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Naming Web Console (was: Web Console) (was: Naming) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.1.CR1) > Bindings of most binding-types can not be created in naming subsystem configuration in Web Console > -------------------------------------------------------------------------------------------------- > > Key: WFLY-6754 > URL: https://issues.jboss.org/browse/WFLY-6754 > Project: WildFly > Issue Type: Bug > Components: Naming, Web Console > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Critical > > When adding bindings in naming subsystem configuration of Web Console, the Add form has wrong mandatory fields. Mandatory fields for bindings are dependent on binding type. > On the other hand, some binding types do not have attributes that the Add form will try to send to the interface, resulting in user being unable to add any binding type besides {{external context}} (for example, adding a simple or lookup binding will result in {{Unknown error}} due to simple binding type not being able to have 'cache' attribute). > For example, {{/subsystem=naming/binding=java\:global\/a:add(binding-type=simple, type=int, value=100)}} would be a legal simple binding inserted through the JBoss CLI: > {code}{"outcome" => "success"}{code} > Adding this same following binding will produce the following error output in Web Console: > {quote}Unknown error > Unexpected HTTP response: 500 > Request > {code}{ > "name" => "java:global/a", > "binding-type" => "simple", > "cache" => false, > "class" => undefined, > "environment" => undefined, > "lookup" => undefined, > "module" => undefined, > "type" => "int", > "value" => "100", > "operation" => "add", > "address" => [ > ("subsystem" => "naming"), > ("binding" => "java:global/a") > ] > }{code} > Response > Internal Server Error > {code}{ > "outcome" => "failed", > "failure-description" => "WFLYNAM0061: Binding type simple can not take a 'cache' attribute", > "rolled-back" => true > }{code}{quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6753) Bindings of most binding-types can not be created in naming subsystem configuration in Web Console

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-6753?page=com.atlassian.jira.plugin.... ] Tomas Hofman moved JBEAP-4952 to WFLY-6753: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6753 (was: JBEAP-4952) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Naming Web Console (was: Web Console) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.GA) > Bindings of most binding-types can not be created in naming subsystem configuration in Web Console > -------------------------------------------------------------------------------------------------- > > Key: WFLY-6753 > URL: https://issues.jboss.org/browse/WFLY-6753 > Project: WildFly > Issue Type: Bug > Components: Naming, Web Console > Affects Versions: 10.0.0.Final > Reporter: Michal Jurc > Assignee: Tomas Hofman > Priority: Critical > > When adding bindings in naming subsystem configuration of Web Console, the Add form has wrong mandatory fields. Mandatory fields for bindings are dependent on binding type. > On the other hand, some binding types do not have attributes that the Add form will try to send to the interface, resulting in user being unable to add any binding type besides {{external context}} (for example, adding a simple or lookup binding will result in {{Unknown error}} due to simple binding type not being able to have 'cache' attribute). > For example, {{/subsystem=naming/binding=java\:global\/a:add(binding-type=simple, type=int, value=100)}} would be a legal simple binding inserted through the JBoss CLI: > {code}{"outcome" => "success"}{code} > Adding this same following binding will produce the following error output in Web Console: > {quote}Unknown error > Unexpected HTTP response: 500 > Request > {code}{ > "name" => "java:global/a", > "binding-type" => "simple", > "cache" => false, > "class" => undefined, > "environment" => undefined, > "lookup" => undefined, > "module" => undefined, > "type" => "int", > "value" => "100", > "operation" => "add", > "address" => [ > ("subsystem" => "naming"), > ("binding" => "java:global/a") > ] > }{code} > Response > Internal Server Error > {code}{ > "outcome" => "failed", > "failure-description" => "WFLYNAM0061: Binding type simple can not take a 'cache' attribute", > "rolled-back" => true > }{code}{quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ] Sebastian Łaskawiec commented on WFCORE-1612: --------------------------------------------- Hey [~ctomc], I rephrased the title and description. The answer to your questions is yes, we use a domain controller to propagate configuration changes to all nodes in the cluster. Now we think how to achieve similar functionality when using Standalone mode. I believe some of the layered products will have similar issues. > Allow applying the same configuration changes to multiple Standalone nodes > -------------------------------------------------------------------------- > > Key: WFCORE-1612 > URL: https://issues.jboss.org/browse/WFCORE-1612 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Sebastian Łaskawiec > Assignee: Brian Stansberry > > I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works. > The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case. > In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1612) Allow applying the same configuration changes to multiple Standalone nodes

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1612?page=com.atlassian.jira.plugi... ] Sebastian Łaskawiec updated WFCORE-1612: ---------------------------------------- Description: I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works. The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case. In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode. was: I would like to request a support for DMR commands in standalone mode. The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case. > Allow applying the same configuration changes to multiple Standalone nodes > -------------------------------------------------------------------------- > > Key: WFCORE-1612 > URL: https://issues.jboss.org/browse/WFCORE-1612 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Sebastian Łaskawiec > Assignee: Brian Stansberry > > I would like to request a supporting configuration changes to multiple standalone nodes the same way as currently DMR in domain mode works. > The main motivation behind that is using WF based Projects (like Infinispan HotRod Server) in the Cloud. By using DMR we can ensure changing configuration on the fly, which is very important in our case. > In Infinispan project we use DMR to propagate configuration changes to all nodes in the cluster (e.g. adding a cache, changing it etc). When considering Cloud deployment we use Standalone mode. It would be nice to find a way to propagate configuration changes to all servers the same way as we do in Domain mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016