May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13484) JSF - submitting empty fields does not work

by Frank Heldt (Jira)

Frank Heldt created WFLY-13484: ---------------------------------- Summary: JSF - submitting empty fields does not work Key: WFLY-13484 URL: https://issues.redhat.com/browse/WFLY-13484 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 19.1.0.Final Reporter: Frank Heldt Assignee: Farah Juma A simple JSF webapp with an input field {{<p:inputMask value="#{myCtrl.num}" mask="?9999" slotChar="" size="4" maxlength="4"/> }} and in the controller {{private Short num; // + getter/setter}} When the input field is empty, the setter is never called on submit. The same webapp under WildFly 19.0.0 works as expected, in this case the setter is called with a null value. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13483) Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13483?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFLY-13483: ---------------------------------- Description: Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. ---- This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a scenario, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. However, as the current undertow subsystem does not have a configurable parameter to reuse it, undertow mod-cluster and reverse-proxy always overwrite X-Forwarded-For request header with its own information. was: Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a case, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. The current implementation is unable to reuse it and overwrites it with its own information. > Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler > ----------------------------------------------------------------------------- > > Key: WFLY-13483 > URL: https://issues.redhat.com/browse/WFLY-13483 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Flavia Rainone > Priority: Major > > Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). > However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. > ---- > This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a scenario, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. > However, as the current undertow subsystem does not have a configurable parameter to reuse it, undertow mod-cluster and reverse-proxy always overwrite X-Forwarded-For request header with its own information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13483) Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13483?page=com.atlassian.jira.plugi... ] Masafumi Miura reassigned WFLY-13483: ------------------------------------- Assignee: Flavia Rainone (was: Brian Stansberry) > Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler > ----------------------------------------------------------------------------- > > Key: WFLY-13483 > URL: https://issues.redhat.com/browse/WFLY-13483 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Flavia Rainone > Priority: Major > > Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). > However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. > This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a case, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. > The current implementation is unable to reuse it and overwrites it with its own information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13483) Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13483?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFLY-13483: ---------------------------------- Affects Version/s: 19.1.0.Final > Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler > ----------------------------------------------------------------------------- > > Key: WFLY-13483 > URL: https://issues.redhat.com/browse/WFLY-13483 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Brian Stansberry > Priority: Major > > Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). > However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. > This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a case, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. > The current implementation is unable to reuse it and overwrites it with its own information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13483) Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13483?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFLY-13483: ---------------------------------- Component/s: Web (Undertow) > Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler > ----------------------------------------------------------------------------- > > Key: WFLY-13483 > URL: https://issues.redhat.com/browse/WFLY-13483 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 19.1.0.Final > Reporter: Masafumi Miura > Assignee: Brian Stansberry > Priority: Major > > Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). > However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. > This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a case, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. > The current implementation is unable to reuse it and overwrites it with its own information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13483) Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler

by Masafumi Miura (Jira)

Masafumi Miura created WFLY-13483: ------------------------------------- Summary: Add reuse-x-forwarded support to mod-cluster filter and reverse-proxy handler Key: WFLY-13483 URL: https://issues.redhat.com/browse/WFLY-13483 Project: WildFly Issue Type: Enhancement Reporter: Masafumi Miura Assignee: Brian Stansberry Undertow has setReuseXForwarded() method in the builder API of ModCluster and ProxyHandler to enable support to reuse X-Forwarded-* request headers (like X-Forwarded-For header). However, the undertow subsystem does not expose it as the configurable parameter of <mod-cluster> and <reverse-proxy>. This parameter is useful when the undertow load balance proxy is backed by another proxy server. In such a case, the front-end proxy adds X-Forwarded-* request headers to provide information about the original requester. The current implementation is unable to reuse it and overwrites it with its own information. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Thomas Darimont (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Thomas Darimont commented on JGRP-2477: --------------------------------------- Likewise - thanks for the quick turnaround :) > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.4 > > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2477: -------------------------------- Applied, thanks and kudos for the nice report and reproducer! Doesn't happen often... > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.4 > > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2477. ---------------------------- Resolution: Done > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.4 > > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2477) Reintroduce support for configuring a JChannel via URL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2477?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2477: --------------------------- Fix Version/s: 4.2.4 Affects Version/s: (was: 5.0.0.Beta1) > Reintroduce support for configuring a JChannel via URL > ------------------------------------------------------ > > Key: JGRP-2477 > URL: https://issues.redhat.com/browse/JGRP-2477 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.2.3 > Reporter: Thomas Darimont > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.4 > > > Infinispan 9.4.x (9.4.19) uses a URL to load the JGroups configuration from the infinispan configuration. > When an external jgroups stack configuration file is used: > See: "Using an external JGroups file" in https://infinispan.org/docs/9.4.x/user_guide/user_guide.html#using_an_ext... > When creating the JGroups stack, infinispan uses the constructor in org.jgroups.JChannel#JChannel(...) which takes a URL as parameter. > See: https://github.com/infinispan/infinispan/blob/9.4.x/core/src/main/java/or... > However this constructor is only present in versions up-to including 4.0.22 https://github.com/belaban/JGroups/blob/4.0.22/src/org/jgroups/JChannel.j... > and was removed in later versions. > Because of this users of infinispan 9.4.x, who use the "Using an external JGroups file" configuration approach cannot upgrade to new JGroups versions, like 4.2.3. > In order to ease upgrading to newer JGroups versions with Infinispan 9.4.x. it would be very kind if the constructor with the URL parameter > could be added back. > I created a pull request to add the constructor {org.jgroups.JChannel#JChannel(java.net.URL)} to master, which can also be cherry-picked for the 4.x branch. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 May 2020