August 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Michal Karm Babacek reopened MODCLUSTER-528: -------------------------------------------- The conclusion doesn't make any sense to me - which systems? Which tomcats? Why would we bring Tomcat 7 dependencies to Tomcat 8 game? When I compile with Tomcat 7 profile, I should need Tomcat 7 dependencies, when I compile with Tomcat 8 profile, I should need only Tomcat 8 dependencies without patching *.java files and without patching pom files. The aforementioned is not possible due to a bug in the Java source code and pom structure. According to the pom, it looks like we offer Tomcat 7 and Tomcat 8 profiles, while in fact we don't (Tomcat 8 profile still depends on Tomcat 7 libs). h3. Suggestion * drop Tomcat 6 from 1.3.x branch and from master, it is not needed there * drop JBossWeb/AS7 from 1.3.x branch and from master, it is not needed there * move Catalina stuff around so as *-PTC7* needs Tomcat 7 dependencies, *-PTC8* needs Tomcat 8 dependencies, *-PTC85* needs Tomcat 8.5 dependencies etc. > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-485) Move CI to Travis

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-485?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-485: -------------------------------------- Fix Version/s: 1.3.4.Final > Move CI to Travis > ----------------- > > Key: MODCLUSTER-485 > URL: https://issues.jboss.org/browse/MODCLUSTER-485 > Project: mod_cluster > Issue Type: Task > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: CI > Fix For: 2.0.0.Alpha1, 1.3.4.Final > > > -I ran into this while adding support for Tomcat 9.- > -What the CI should be testing, give the number of JDKs and different container versions that we support, we should build with respective jdks and versions:- > -jdk6 + mvn verify -PTC6- > -jdk7 + mvn verify -PTC7- > -jdk7 + mvn verify -PAS7- > -jdk8 + mvn verify -PTC8- > -jdk7/8 + mvn verify- > The situation has changed since original proposal fixing CI with proper dependencies for tomcat versions. Taking into account support for legacy containers has been dropped in master, so now we have desired combinations: > * jdk7 + jdk8 and default profile (excludes Tomcat 9) -> 3 combos on travis > * jdk 8 + Tomcat 9 profile -> 1 combo on travis > See http://tomcat.apache.org/whichversion.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-485) Move CI to Travis

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-485?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-485. ------------------------------------- Resolution: Done Labels: CI (was: ) Merged to 1.3.x and master. Let me note that this only tests the Java parts on different JDKs. > Move CI to Travis > ----------------- > > Key: MODCLUSTER-485 > URL: https://issues.jboss.org/browse/MODCLUSTER-485 > Project: mod_cluster > Issue Type: Task > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: CI > Fix For: 2.0.0.Alpha1, 1.3.4.Final > > > -I ran into this while adding support for Tomcat 9.- > -What the CI should be testing, give the number of JDKs and different container versions that we support, we should build with respective jdks and versions:- > -jdk6 + mvn verify -PTC6- > -jdk7 + mvn verify -PTC7- > -jdk7 + mvn verify -PAS7- > -jdk8 + mvn verify -PTC8- > -jdk7/8 + mvn verify- > The situation has changed since original proposal fixing CI with proper dependencies for tomcat versions. Taking into account support for legacy containers has been dropped in master, so now we have desired combinations: > * jdk7 + jdk8 and default profile (excludes Tomcat 9) -> 3 combos on travis > * jdk 8 + Tomcat 9 profile -> 1 combo on travis > See http://tomcat.apache.org/whichversion.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-485) Move CI to Travis

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-485?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-485: -------------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/200, https://github.com/modcluster/mod_cluster/pull/214 (was: https://github.com/modcluster/mod_cluster/pull/200) > Move CI to Travis > ----------------- > > Key: MODCLUSTER-485 > URL: https://issues.jboss.org/browse/MODCLUSTER-485 > Project: mod_cluster > Issue Type: Task > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: CI > Fix For: 2.0.0.Alpha1, 1.3.4.Final > > > -I ran into this while adding support for Tomcat 9.- > -What the CI should be testing, give the number of JDKs and different container versions that we support, we should build with respective jdks and versions:- > -jdk6 + mvn verify -PTC6- > -jdk7 + mvn verify -PTC7- > -jdk7 + mvn verify -PAS7- > -jdk8 + mvn verify -PTC8- > -jdk7/8 + mvn verify- > The situation has changed since original proposal fixing CI with proper dependencies for tomcat versions. Taking into account support for legacy containers has been dropped in master, so now we have desired combinations: > * jdk7 + jdk8 and default profile (excludes Tomcat 9) -> 3 combos on travis > * jdk 8 + Tomcat 9 profile -> 1 combo on travis > See http://tomcat.apache.org/whichversion.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-528. ------------------------------------- Fix Version/s: (was: 2.0.0.Alpha1) Resolution: Rejected We agreed on the call today that we don't want to keep introducing workarounds for different building systems. Other linux distributions do have tomcat7 package and thus this can be easily build against. Fedora seems to keep following the approach where even containers are kept at one version in the repo, e.g. in fedora 24 its tomcat8. IIUC this needs to be fixed by creating a meta package that contains tomcat7 so that modcluster can be build using it. [~jfclere] can comment more. > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-528) Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-528?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-528: -------------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/modcluster/mod_cluster/pull/211) Rejecting PR https://github.com/modcluster/mod_cluster/pull/211 > Re-think catalina/tomcat dependencies so as it is possible to build without tomcat7 API > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-528 > URL: https://issues.jboss.org/browse/MODCLUSTER-528 > Project: mod_cluster > Issue Type: Enhancement > Affects Versions: 1.3.3.Final > Reporter: Michal Karm Babacek > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > It is not possible (or I'm doing something wrong) to build mod_cluster Tomcat libs with Tomcat 8-only API. > I hit this problem with RPM build on Fedora where I cannot download random stuff from maven central and I need to specify dependencies beforehand. > h3. Description > * container/catalina contains calls to API that is deprecated in Tomcat 7 and missing in Tomcat 8, so I have to apply this patch: [MODCLUSTER-528-CatalinaContext.java.patch|https://github.com/Karm/mod_clu...] before build > * profiles and test dependencies and Servlet API dependencies needs hacks to build without Tomcat 7 too: see other patches in [mod_cluster-fedora-packages/|https://github.com/Karm/mod_cluster-fedora-p...] > h3. Suggestion > * architecture dependencies so as it is possible to build mod_cluster with Tomcat 8 API only (and Tomcat 7 API only) > * drop Tomcat 6 and JBossWeb from 1.3.x as they are not used in 1.3.x anyway (last use of Tomcat 6 and JBossWeb is 1.2.x) > h3. Fedora 24 offers only Tomcat 8 > ...so does it even make sense to offer users Tomcat 7 libs RPM? At the moment, I have it disabled. Note: Former mod_cluster RPM (1.2.6) hasn't been distributing any usable tomcat integration; it has been AS7/JBossWeb one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 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: -------------------------------------- Component/s: Core & Container Integration (Java) > 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 > Components: Core & Container Integration (Java) > Affects Versions: 1.3.3.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > 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)

7 years, 8 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: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 > 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 > Components: Core & Container Integration (Java) > Affects Versions: 1.3.3.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > 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)

7 years, 8 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: -------------------------------------- Affects Version/s: 1.3.3.Final > 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 > Components: Core & Container Integration (Java) > Affects Versions: 1.3.3.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 2.0.0.Alpha1 > > > 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)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- Michal Karm Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1309598|https://bugzilla.redhat.com/show_bug.cgi?id=1309598] from ON_QA to VERIFIED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.2.14.Final, 1.3.4.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 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