[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2168:
--------------------------------
Fair enough, I added JChannel(List) and deprecated JChannel(Collection).
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2168) JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-2168?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-2168:
------------------------------------
{quote}First off: I cannot change the Collection to a List as this would be an API change.{quote}
Why can't you add a new constructor that accepts a List and deprecate the old one?
> JChannel(Collection<Protocol>) constructor clears protocol properties with non-default converter whose associated system property is not defined
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2168
> URL: https://issues.jboss.org/browse/JGRP-2168
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.13, 4.0.1
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> WildFly 11 recently started using the new JChannel(Protocol...) constructor for creating channels. This has resulted in the inability to configure certain protocol properties, most notably, initial_hosts for TCPPING.
> Because this constructor calls resolveAndAssignFields(...) with an empty map, if a property was explicitly set, and its associated system property does not exist, and that property uses a non-default converter, then it will have its value undefined (or, more specifically, set to whatever the converter does with a null value).
> Additionally, if the assocated system property did exist, it would take precedence over an explicitly set value. I don't think that's a good idea.
> Consider the following:
> {code:java}
> TCP transport = new TCP();
> transport.setBindAddress(InetAddress.getLocalHost());
> transport.setBindPort(9600);
> TCPPING ping = new TCPPING();
> ping.setInitialHosts(Collections.singletonList(new IpAddress(transport.getBindAddress(), transport.getBindPort())));
> JChannel channel = new JChannel(transport, ping);
> assert !ping.getInitialHosts().isEmpty() : "No initial hosts!";
> {code}
> Side note: new JChannel(Collection<Protocol>) should really be new JChannel(List<Protocol>), since the collection should be ordered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2483) There is missing CS integration with core management
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2483?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-2483:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Darran Lofthouse)
> There is missing CS integration with core management
> ----------------------------------------------------
>
> Key: WFCORE-2483
> URL: https://issues.jboss.org/browse/WFCORE-2483
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> Priority is BLOCKER because this issue blocks RFE verification https://issues.jboss.org/browse/EAP7-538
> There must be credential store integration with core management as is mentioned in requirements of RFE.
> *management/security-realm*
> *management/security-realm/authentication/truststore* keystore-password
> *management/security-realm/server-identity/ssl* key-password and keystore-password
> *management/security-realm/server-identity/secret*
> *management/security-realm/authentication/users*
> But *security-realm* is deprecated, these resources have this description:
> {code}
> The security-realm configuration is deprecated and may be removed or moved in future versions.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1100) Configured set-protocol in Elytron Client configuration file is not used
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1100?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1100:
-------------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> Configured set-protocol in Elytron Client configuration file is not used
> ------------------------------------------------------------------------
>
> Key: ELY-1100
> URL: https://issues.jboss.org/browse/ELY-1100
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.Beta34
> Reporter: Ondrej Lukas
> Assignee: David Lloyd
> Priority: Blocker
>
> When some configuration in Elytron Client configuration file uses set-protocol then value of this element is not used for outgoing connection. Elements set-host and set-port are used correctly.
> Following authentication configuration part of wildfly-config.xml should use URL {{remote+http://localhost:9990}} for outgoing connection, but protocol {{remote+http}} from {{set-protocol}} is not used:
> {code}
> <authentication-configurations>
> <configuration name="auth-config">
> <set-user-name name="user"/>
> <set-protocol name="remote+http"/>
> <set-host name="localhost"/>
> <set-port number="9990"/>
> <credentials>
> <clear-password password="password"/>
> </credentials>
> </configuration>
> </authentication-configurations>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1100) Configured set-protocol in Elytron Client configuration file is not used
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1100?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1100:
---------------------------------------
[~dmlloyd] Did this one result in any Elytron change?
> Configured set-protocol in Elytron Client configuration file is not used
> ------------------------------------------------------------------------
>
> Key: ELY-1100
> URL: https://issues.jboss.org/browse/ELY-1100
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Affects Versions: 1.1.0.Beta34
> Reporter: Ondrej Lukas
> Assignee: David Lloyd
> Priority: Blocker
>
> When some configuration in Elytron Client configuration file uses set-protocol then value of this element is not used for outgoing connection. Elements set-host and set-port are used correctly.
> Following authentication configuration part of wildfly-config.xml should use URL {{remote+http://localhost:9990}} for outgoing connection, but protocol {{remote+http}} from {{set-protocol}} is not used:
> {code}
> <authentication-configurations>
> <configuration name="auth-config">
> <set-user-name name="user"/>
> <set-protocol name="remote+http"/>
> <set-host name="localhost"/>
> <set-port number="9990"/>
> <credentials>
> <clear-password password="password"/>
> </credentials>
> </configuration>
> </authentication-configurations>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2779) Improve help message in module CLI operation
by Martin Stefanko (JIRA)
Martin Stefanko created WFCORE-2779:
---------------------------------------
Summary: Improve help message in module CLI operation
Key: WFCORE-2779
URL: https://issues.jboss.org/browse/WFCORE-2779
Project: WildFly Core
Issue Type: Bug
Affects Versions: 3.0.0.Beta18
Reporter: Martin Stefanko
Assignee: Martin Stefanko
Priority: Minor
Improve help message in module CLI operation:
{{module --help}}
--resources and --absolute-resources description contains example of path separator, example is java.io.File.pathSeparatorChar. This example could be confusing for EAP administrators without experience with java. It would be better to mention example for Windows and Linux OS:
So I suggest to replace this:
{{separated by a filesystem-specific path separator, i.e. java.io.File.pathSeparatorChar.}}
by something like this:
{{separated by a filesystem-specific path separator, i.e. '/' for Linux and '\' for Windows.}}
This help message is stored in WF-Core in /cli/src/main/resources/help/module.txt
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina edited comment on WFCORE-2691 at 5/9/17 5:06 AM:
------------------------------------------------------------
ehm, true, as the *credential-store* can be any key-store based, creating WFCORE-2777 / JBEAP-10799 for it.
was (Author: honza889):
ehm, true, as the *credential-store* can be any key-store based, creating WFCORE-2777 for it.
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years