[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 resolved JGRP-2168.
----------------------------
Resolution: Done
> 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)
7 years, 8 months
[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:
--------------------------------
I added a test for TCPGOSSIP (test: TCPPING_Test) and it passes. Committing my changes now.
> 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)
7 years, 8 months
[JBoss JIRA] (WFCORE-2756) Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2756?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2756:
------------------------------------
Assignee: Yeray Borges
> Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2756
> URL: https://issues.jboss.org/browse/WFCORE-2756
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Yeray Borges
> Priority: Critical
>
> {{rotating-file-audit}} throws {{IllegalArgumentException}} if user tries to add a new {{rotating-audit-file}} and does not specify {{suffix}} property.
> Steps to reproduce: {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log)}}
> Following output is given in jboss-cli
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}},
> "rolled-back" => true
> }
> {code}
> and following one in server log:
> {code}
> 12:45:41,381 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.security-event-listener.rotating-audit: org.jboss.msc.service.StartException in service org.wildfly.security.security-event-listener.rotating-audit: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 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.IllegalArgumentException: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.wildfly.security.audit.RotatingFileAuditEndpoint$Builder.setSuffix(RotatingFileAuditEndpoint.java:289)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$2.lambda$getValueSupplier$2(AuditResourceDefinitions.java:235)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 12:45:41,382 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("rotating-file-audit-log" => "rotating-audit")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}}
> {code}
> Note: there is an easy workaround - if user specifies {{suffix}} property then adding a new {{rotating-audit-file}} works fine, e.g. {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,suffix=y-M-d)}} passes successfully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2782) [GSS](7.1.x) Executing CLI file fails with encoding ANSI (Windows-1252)
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2782?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved JBEAP-10811 to WFCORE-2782:
------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2782 (was: JBEAP-10811)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR15)
(was: 7.1.0.DR17)
Affects Testing: (was: Regression)
> [GSS](7.1.x) Executing CLI file fails with encoding ANSI (Windows-1252)
> -----------------------------------------------------------------------
>
> Key: WFCORE-2782
> URL: https://issues.jboss.org/browse/WFCORE-2782
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> Executing the CLI with file encoding ANSI (Windows-1252) where characters include German umlauts (ä, ö, ü) fails.
> This worked in EAP 7.0.0, but fails in 7.1.0 Alpha. Also present in DR17
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ken Wills updated WFCORE-2746:
------------------------------
Description:
Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
There are a number of aspects to this, for which I'll create subtasks.
Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
-org.jboss.as.test.integration.security.perimeter.* [2]-
-org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
-org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
org.jboss.as.test.integration.security.credentialreference [2]
integration/elytron/
[1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
[2] Currently using Arquillian.
was:
Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
There are a number of aspects to this, for which I'll create subtasks.
Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
-org.jboss.as.test.integration.security.perimeter.* [2]-
-org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
-org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
org.jboss.as.test.integration.security.credentialreference [2]
[1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
[2] Currently using Arquillian.
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2]
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8735) The WildFly pom.xml is overriding the version of WildFly Client Config
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8735?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-8735:
------------------------------
Summary: The WildFly pom.xml is overriding the version of WildFly Client Config (was: The EAP pom.xml is overriding the version of WildFly Client Config)
> The WildFly pom.xml is overriding the version of WildFly Client Config
> ----------------------------------------------------------------------
>
> Key: WFLY-8735
> URL: https://issues.jboss.org/browse/WFLY-8735
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> This was introduce under the following commit to address transitive dependency issues: -
> commit b49586d5c90e673aa1abceef3c047257da6cb19e
> Author: Tomaz Cerar <tomaz.cerar(a)gmail.com>
> Date: Mon Apr 24 17:13:16 2017 +0200
> JBEAP-10175 JBEAP-10174 Unmanaged transitive dependencies in EJB client BOM dependency tree
> However the version override means a version upgrade in core does not get applied to EAP.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months