[JBoss JIRA] (WFLY-9935) Add security configuration for Infinispan remote cache store
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-9935:
------------------------------------
Summary: Add security configuration for Infinispan remote cache store
Key: WFLY-9935
URL: https://issues.jboss.org/browse/WFLY-9935
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 12.0.0.Beta1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
A remote cache store will reference configuration introduced with WFLY-6634 which incorporates security configuration.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9294) Add security configuration for Infinispan remote cache store
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9294?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9294:
---------------------------------
Description: A remote cache store will reference configuration introduced with WFLY-6634 which incorporates security configuration. (was: The remote cache store will reference configuration introduced with WFLY-6634 which incorporates security configuration. )
> Add security configuration for Infinispan remote cache store
> ------------------------------------------------------------
>
> Key: WFLY-9294
> URL: https://issues.jboss.org/browse/WFLY-9294
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 12.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
>
> A remote cache store will reference configuration introduced with WFLY-6634 which incorporates security configuration.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-45) Foreman Openshift Clusters
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-45?page=com.atlassian.jira.plugin.s... ]
Guilherme Baufaker Rêgo resolved SWSQE-45.
------------------------------------------
Resolution: Done
- It is possible to install Openshift 3.7 on Foreman's VMs with minimum requirement (16GB RAM and 40 GB free under /var?) by executing the openshift-ansible-playbooks
> Foreman Openshift Clusters
> --------------------------
>
> Key: SWSQE-45
> URL: https://issues.jboss.org/browse/SWSQE-45
> Project: Swift Sunshine QE
> Issue Type: Task
> Reporter: Guilherme Baufaker Rêgo
> Assignee: Guilherme Baufaker Rêgo
>
> - Considering that we need openshift clusters, I think it would be good to revive the idea of having openshift clusters based on foreman VMs
> - Minimum Requirement:
> - 16 GB of RAM and 40 GB of empty space under var
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-47) Create a Confluence Test Plan Format
by Guilherme Baufaker Rêgo (JIRA)
Guilherme Baufaker Rêgo created SWSQE-47:
--------------------------------------------
Summary: Create a Confluence Test Plan Format
Key: SWSQE-47
URL: https://issues.jboss.org/browse/SWSQE-47
Project: Swift Sunshine QE
Issue Type: Bug
Reporter: Guilherme Baufaker Rêgo
Assignee: Michael Foley
It is possible to create a Confluence Test Plan Format and reuse it for our needs. It suit better than using Product Requirements
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-9854:
------------------------------------
Just responding to the ask, that I agree its not a compatibility concern. Anything that was previously invalid but did not generate an error may generate an error in the future. In some cases we can try to be nice and be liberal in what we accept, but thats not always practical.
> jgroups-channel cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (ELY-1526) Update the default provider supplier to be an aggregate of the WildFlyElytronProvider plus the installed providers in order to ensure the WildFlyElytronProvider comes first
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1526?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1526:
----------------------------
Description:
As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers.
Update the default provider supplier to be an aggregate of:
# WildFlyElytronProvider
# The security providers loaded using the service loader mechanism ensuring that any provider that is already an installed provider is skipped
# The installed providers
For WildFly 13, we can look at enhancing this by introducing a security provider selector mechanism. This is tracked in ELY-1530.
was:As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers. As discussed with David Lloyd, the best way to fix this is likely to just have the default supplier be an aggregate of the WildFlyElytronProvider plus the installed providers and drop the service loader part.
> Update the default provider supplier to be an aggregate of the WildFlyElytronProvider plus the installed providers in order to ensure the WildFlyElytronProvider comes first
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1526
> URL: https://issues.jboss.org/browse/ELY-1526
> Project: WildFly Elytron
> Issue Type: Task
> Components: Authentication Client
> Reporter: Farah Juma
> Assignee: Farah Juma
> Fix For: 1.2.2.Final
>
>
> As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers.
> Update the default provider supplier to be an aggregate of:
> # WildFlyElytronProvider
> # The security providers loaded using the service loader mechanism ensuring that any provider that is already an installed provider is skipped
> # The installed providers
> For WildFly 13, we can look at enhancing this by introducing a security provider selector mechanism. This is tracked in ELY-1530.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month