August 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-532) Deprecate use of the term "jvmRoute" and its variants to be concise with apache terminology "route"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-532?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-532: -------------------------------------- Description: Renamed in jk verion 1.2.20. {noformat} The attribute has been renamed from jvm_route to route in jk 1.2.20. {noformat} See https://tomcat.apache.org/connectors-doc/reference/workers.html We need to keep in the value in MCMP protocol, see https://developer.jboss.org/wiki/Mod-ClusterManagementProtocol for usage was: Renamed in jk verion 1.2.20. {noformat} The attribute has been renamed from jvm_route to route in jk 1.2.20. {noformat} See https://tomcat.apache.org/connectors-doc/reference/workers.html > Deprecate use of the term "jvmRoute" and its variants to be concise with apache terminology "route" > --------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-532 > URL: https://issues.jboss.org/browse/MODCLUSTER-532 > Project: mod_cluster > Issue Type: Enhancement > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Renamed in jk verion 1.2.20. > {noformat} > The attribute has been renamed from jvm_route to route in jk 1.2.20. > {noformat} > See https://tomcat.apache.org/connectors-doc/reference/workers.html > We need to keep in the value in MCMP protocol, see https://developer.jboss.org/wiki/Mod-ClusterManagementProtocol for usage -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-532) Deprecate use of the term "jvmRoute" and its variants to be concise with apache terminology "route"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-532?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-532: -------------------------------------- Summary: Deprecate use of the term "jvmRoute" and its variants to be concise with apache terminology "route" (was: Deprecate use of the term "jvmRoute" and its variants, be concise with apache terminology "route") > Deprecate use of the term "jvmRoute" and its variants to be concise with apache terminology "route" > --------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-532 > URL: https://issues.jboss.org/browse/MODCLUSTER-532 > Project: mod_cluster > Issue Type: Enhancement > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Renamed in jk verion 1.2.20. > {noformat} > The attribute has been renamed from jvm_route to route in jk 1.2.20. > {noformat} > See https://tomcat.apache.org/connectors-doc/reference/workers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-532) Deprecate use of the term "jvmRoute" and its variants, be concise with apache terminology "route"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-532?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-532: -------------------------------------- Summary: Deprecate use of the term "jvmRoute" and its variants, be concise with apache terminology "route" (was: Deprecate use of "jvmRoute" and its variants, be concise with apache terminology "route") > Deprecate use of the term "jvmRoute" and its variants, be concise with apache terminology "route" > ------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-532 > URL: https://issues.jboss.org/browse/MODCLUSTER-532 > Project: mod_cluster > Issue Type: Enhancement > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Renamed in jk verion 1.2.20. > {noformat} > The attribute has been renamed from jvm_route to route in jk 1.2.20. > {noformat} > See https://tomcat.apache.org/connectors-doc/reference/workers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-532) Deprecate use of "jvmRoute" and its variants, be concise with apache terminology "route"

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-532: ----------------------------------------- Summary: Deprecate use of "jvmRoute" and its variants, be concise with apache terminology "route" Key: MODCLUSTER-532 URL: https://issues.jboss.org/browse/MODCLUSTER-532 Project: mod_cluster Issue Type: Enhancement Reporter: Radoslav Husar Assignee: Jean-Frederic Clere Renamed in jk verion 1.2.20. {noformat} The attribute has been renamed from jvm_route to route in jk 1.2.20. {noformat} See https://tomcat.apache.org/connectors-doc/reference/workers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-532) Deprecate use of "jvmRoute" and its variants, be concise with apache terminology "route"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-532?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-532: ----------------------------------------- Assignee: Radoslav Husar (was: Jean-Frederic Clere) > Deprecate use of "jvmRoute" and its variants, be concise with apache terminology "route" > ---------------------------------------------------------------------------------------- > > Key: MODCLUSTER-532 > URL: https://issues.jboss.org/browse/MODCLUSTER-532 > Project: mod_cluster > Issue Type: Enhancement > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Renamed in jk verion 1.2.20. > {noformat} > The attribute has been renamed from jvm_route to route in jk 1.2.20. > {noformat} > See https://tomcat.apache.org/connectors-doc/reference/workers.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-502) Upgrade MulticastSocket to MulticastChannel

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-502?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-502: -------------------------------------- Status: Open (was: Pull Request Sent) > Upgrade MulticastSocket to MulticastChannel > ------------------------------------------- > > Key: MODCLUSTER-502 > URL: https://issues.jboss.org/browse/MODCLUSTER-502 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > * upgrade requirement to JDK7 > * simply AdvertiseListenerImpl > * remove unused AdvertiseListener lifecycle methods with AutoCloseable > * add tests on IPv6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Consider elimination automagic

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Summary: Consider elimination automagic (was: Stop advocating and remove auto-magic aspects from the project) > Consider elimination automagic > ------------------------------ > > Key: MODCLUSTER-531 > URL: https://issues.jboss.org/browse/MODCLUSTER-531 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > I am proposing we abandon automagic as much as possible. > h1. Problem > The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: > # insecure (listening on all interfaces, allow from all, default security key "changeme!") > # difficult to debug (not clear what is the actual configuration) > # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config) > h1. Areas > There are several areas where automagic happens. > h5. Advertised address of the proxy > There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. > h5. Advertise interfaces > The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly. > h5. Connector address > If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface. > h5. Connector selection > This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Consider eliminating automagic

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Summary: Consider eliminating automagic (was: Consider elimination automagic) > Consider eliminating automagic > ------------------------------ > > Key: MODCLUSTER-531 > URL: https://issues.jboss.org/browse/MODCLUSTER-531 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > I am proposing we abandon automagic as much as possible. > h1. Problem > The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: > # insecure (listening on all interfaces, allow from all, default security key "changeme!") > # difficult to debug (not clear what is the actual configuration) > # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config) > h1. Areas > There are several areas where automagic happens. > h5. Advertised address of the proxy > There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. > h5. Advertise interfaces > The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly. > h5. Connector address > If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface. > h5. Connector selection > This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Description: I am proposing we abandon automagic as much as possible. h1. Problem The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: # insecure (listening on all interfaces, allow from all, default security key "changeme!") # difficult to debug (not clear what is the actual configuration) # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config) h1. Areas There are several areas where automagic happens. h5. Advertised address of the proxy There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. h5. Advertise interfaces The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly. h5. Connector address If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface. h5. Connector selection This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. was: I am proposing we abandon automagic as much as possible. h1. Problem The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: # insecure (listening on all interfaces, allow from all, default security key "changeme!") # difficult to debug (not clear what is the actual configuration) # unstable installations (seemingly unrelated aspects like adding an interface can break advertised address) h1. Areas There are several areas where automagic happens. h5. Advertised address of the proxy There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. h5. Connector selection This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. > Stop advocating and remove auto-magic aspects from the project > -------------------------------------------------------------- > > Key: MODCLUSTER-531 > URL: https://issues.jboss.org/browse/MODCLUSTER-531 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > I am proposing we abandon automagic as much as possible. > h1. Problem > The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: > # insecure (listening on all interfaces, allow from all, default security key "changeme!") > # difficult to debug (not clear what is the actual configuration) > # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config) > h1. Areas > There are several areas where automagic happens. > h5. Advertised address of the proxy > There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. > h5. Advertise interfaces > The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly. > h5. Connector address > If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface. > h5. Connector selection > This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-531) Stop advocating and remove auto-magic aspects from the project

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-531: -------------------------------------- Description: I am proposing we abandon automagic as much as possible. h1. Problem The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: # insecure (listening on all interfaces, allow from all, default security key "changeme!") # difficult to debug (not clear what is the actual configuration) # unstable installations (seemingly unrelated aspects like adding an interface can break advertised address) h1. Areas There are several areas where automagic happens. h5. Advertised address of the proxy There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. h5. Connector selection This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. was: I am proposing we abandon automagic as much as possible. Problem The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: # insecure (listening on all interfaces, allow from all, default security key "changeme!") # difficult to debug (not clear what is the actual configuration) # unstable installations (seemingly unrelated aspects like adding an interface can break advertised address) Th > Stop advocating and remove auto-magic aspects from the project > -------------------------------------------------------------- > > Key: MODCLUSTER-531 > URL: https://issues.jboss.org/browse/MODCLUSTER-531 > Project: mod_cluster > Issue Type: Enhancement > Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > I am proposing we abandon automagic as much as possible. > h1. Problem > The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are: > # insecure (listening on all interfaces, allow from all, default security key "changeme!") > # difficult to debug (not clear what is the actual configuration) > # unstable installations (seemingly unrelated aspects like adding an interface can break advertised address) > h1. Areas > There are several areas where automagic happens. > h5. Advertised address of the proxy > There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed. > h5. Connector selection > This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2016