buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/1206 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch tomcat/trunk] 1678674 Blamelist: kfujino BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-8-trunk
The Buildbot has detected a restored build on builder tomcat-8-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-8-trunk/builds/250 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' triggered this build Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1678675 Blamelist: kfujino Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1678691 - /tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Author: kfujino Date: Mon May 11 08:35:14 2015 New Revision: 1678691 URL: http://svn.apache.org/r1678691 Log: remove unused import. Modified: tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Modified: tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java URL: http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=1678691&r1=1678690&r2=1678691&view=diff == --- tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java (original) +++ tomcat/tc8.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Mon May 11 08:35:14 2015 @@ -40,7 +40,6 @@ import org.apache.catalina.ha.ClusterMes import org.apache.catalina.ha.ClusterSession; import org.apache.catalina.session.ManagerBase; import org.apache.catalina.session.StandardSession; -import org.apache.catalina.tribes.io.ReplicationStream; import org.apache.catalina.tribes.tipis.ReplicatedMapEntry; import org.apache.tomcat.util.res.StringManager; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1678690 - /tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Author: kfujino Date: Mon May 11 08:34:29 2015 New Revision: 1678690 URL: http://svn.apache.org/r1678690 Log: remove unused import. Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=1678690&r1=1678689&r2=1678690&view=diff == --- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java (original) +++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Mon May 11 08:34:29 2015 @@ -40,7 +40,6 @@ import org.apache.catalina.ha.ClusterMes import org.apache.catalina.ha.ClusterSession; import org.apache.catalina.session.ManagerBase; import org.apache.catalina.session.StandardSession; -import org.apache.catalina.tribes.io.ReplicationStream; import org.apache.catalina.tribes.tipis.ReplicatedMapEntry; import org.apache.juli.logging.Log; import org.apache.juli.logging.LogFactory; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1678339 - in /tomcat/trunk: conf/ java/org/apache/catalina/filters/ webapps/docs/config/
On 09/05/2015 08:45, Martin Grigorov wrote:
> Hi Mark,
>
> On Fri, May 8, 2015 at 3:32 PM, wrote:
>
>> Author: markt
>> Date: Fri May 8 12:32:11 2015
>> New Revision: 1678339
>>
>> URL: http://svn.apache.org/r1678339
>> Log:
>> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=54618
>> Add the HSTS header by default as recommended by RFC 7527
>> +public void setHstsMaxAgeSeconds(int hstsMaxAgeSeconds) {
>> +if (hstsMaxAgeSeconds < 0) {
>> +hstsMaxAgeSeconds = 0;
>>
>
> 1. Is 'this.' missing here ? ^^
It is. Thanks for catching that. I'll get that fixed.
> 2. Who is responsible to call the setters? I'd expect filter init-params to
> be used but since they are not read in #init() it seems there is an other
> way.
That should be handled in FilerBase.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1678694 - /tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
Author: markt
Date: Mon May 11 08:53:05 2015
New Revision: 1678694
URL: http://svn.apache.org/r1678694
Log:
Make sure the field is set.
Spotted by Martin Grigorov.
Modified:
tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
Modified:
tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java?rev=1678694&r1=1678693&r2=1678694&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
Mon May 11 08:53:05 2015
@@ -138,7 +138,7 @@ public class HttpHeaderSecurityFilter ex
public void setHstsMaxAgeSeconds(int hstsMaxAgeSeconds) {
if (hstsMaxAgeSeconds < 0) {
-hstsMaxAgeSeconds = 0;
+this.hstsMaxAgeSeconds = 0;
} else {
this.hstsMaxAgeSeconds = hstsMaxAgeSeconds;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
On 08/05/2015 23:49, Rémy Maucherat wrote: > 2015-05-08 21:14 GMT+02:00 Mark Thomas : > >> I'd like to back-port this but before I do I'd like to hear other >> people's views on the following? >> >> - Should it be back-ported to 8.0.x >> - Should it be enabled by default >> - Should it be back-ported to 7.0.x >> - Should it be enabled by default >> - Should it be back-ported to 6.0.x >> - Should it be enabled by default >> >> My own views are: >> Yes/No >> Yes/No >> No/Not applicable >> > +1 > > No for enabling it by default in 9.0.x as well. The catalyst for work this was reading RFC 7525 [1]. That got me thinking about similar headers. In [1] HSTS support is a MUST and using it is a SHOULD. On that basis I think 9.0.x should use it by default unless there is a really good reason not to. While the other headers are not required by any RFC (as far as I am aware) they are good for security so again I think they should be enabled by default unless there is a good reason not to. Mark [1] https://www.rfc-editor.org/rfc/rfc7525.txt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test-apr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 43 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-test-apr : Tomcat 9.x, a web server implementing the Java Servlet 4.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/logs-APR -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build) Work ended in a state of : Failed Elapsed: 36 mins 3 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.2-SNAPSHOT.jar -Dtest.reports=output/logs-APR -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150511-native-src.tar.gz -Dexamples.sources.skip=true -Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.4-201406061215/ecj-4.4.jar -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native-trunk/dest-20150511/lib -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20150511.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150511-native-src.tar.gz -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false -Dtest.openssl.path=/srv/gump/public/workspace/openssl-master/dest-20150511/bin/openssl -Dexecute.test.apr=true -Dtest.excludePerformance=true -Dexecute.test.nio2=false -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.4-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/out
svn commit: r1678701 - in /tomcat/trunk/java/org/apache/jasper: resources/LocalStrings.properties servlet/TldScanner.java
Author: markt
Date: Mon May 11 09:25:01 2015
New Revision: 1678701
URL: http://svn.apache.org/r1678701
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=56438
Add debug logging for TLD found/not-found in JARs, resource paths and
directories.
Based on a patch by VIN.
Modified:
tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
tomcat/trunk/java/org/apache/jasper/servlet/TldScanner.java
Modified: tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties?rev=1678701&r1=1678700&r2=1678701&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties Mon
May 11 09:25:01 2015
@@ -389,7 +389,12 @@ jsp.message.jsp_unload_check=Checking JS
xmlParser.skipBomFail=Failed to skip BOM when parsing XML input stream
+jsp.tldCache.noTldInResourcePath=No TLD files were found in resource path
[{0}].
+jsp.tldCache.tldInResourcePath=TLD files were found in resource path [{0}].
+jsp.tldCache.noTldInDir=No TLD files were found in directory [{0}].
+jsp.tldCache.tldInDir=TLD files were found in directory [{0}].
jsp.tldCache.noTldInJar=No TLD files were found in [{0}]. Consider adding the
JAR to the tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
CATALINA_BASE/conf/catalina.properties file.
+jsp.tldCache.tldInJar=TLD files were found in JAR [{0}].
jsp.tldCache.noTldSummary=At least one JAR was scanned for TLDs yet contained
no TLDs. Enable debug logging for this logger for a complete list of JARs that
were scanned but no TLDs were found in them. Skipping unneeded JARs during
scanning can improve startup time and JSP compilation time.
#ELInterpreter
Modified: tomcat/trunk/java/org/apache/jasper/servlet/TldScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/TldScanner.java?rev=1678701&r1=1678700&r2=1678701&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/servlet/TldScanner.java (original)
+++ tomcat/trunk/java/org/apache/jasper/servlet/TldScanner.java Mon May 11
09:25:01 2015
@@ -220,6 +220,7 @@ public class TldScanner {
protected void scanResourcePaths(String startPath)
throws IOException, SAXException {
+boolean found = false;
Set dirList = context.getResourcePaths(startPath);
if (dirList != null) {
for (String path : dirList) {
@@ -232,13 +233,24 @@ public class TldScanner {
} else if (path.startsWith("/WEB-INF/tags/")) {
// JSP 7.3.1: in /WEB-INF/tags only consider implicit.tld
if (path.endsWith("/implicit.tld")) {
+found = true;
parseTld(path);
}
} else if (path.endsWith(TLD_EXT)) {
+found = true;
parseTld(path);
}
}
}
+if (found) {
+if (log.isDebugEnabled()) {
+
log.debug(Localizer.getMessage("jsp.tldCache.tldInResourcePath", startPath));
+}
+} else {
+if (log.isDebugEnabled()) {
+
log.debug(Localizer.getMessage("jsp.tldCache.noTldInResourcePath", startPath));
+}
+}
}
/**
@@ -279,6 +291,7 @@ public class TldScanner {
class TldScannerCallback implements JarScannerCallback {
private boolean foundJarWithoutTld = false;
+private boolean foundFileWithoutTld = false;
@Override
public void scan(JarURLConnection urlConn, String webappPath,
@@ -305,11 +318,14 @@ public class TldScanner {
}
}
}
-if (!found) {
+if (found) {
+if (log.isDebugEnabled()) {
+log.debug(Localizer.getMessage("jsp.tldCache.tldInJar",
jarURL.toString()));
+}
+} else {
foundJarWithoutTld = true;
if (log.isDebugEnabled()) {
-log.debug(Localizer.getMessage("jsp.tldCache.noTldInJar",
-jarURL.toString()));
+log.debug(Localizer.getMessage("jsp.tldCache.noTldInJar",
jarURL.toString()));
}
}
}
@@ -321,6 +337,7 @@ public class TldScanner {
if (!metaInf.isDirectory()) {
return;
}
+foundFileWithoutTld = false;
final Path filePath = file.toPath();
Files.walkFileTree(metaInf.toPath(), new SimpleFileVisitor()
{
@Override
@@ -332,6 +349,7 @@ public class TldScanner {
[Bug 56438] If jar scan does not find context config or TLD config, log a message
https://bz.apache.org/bugzilla/show_bug.cgi?id=56438
--- Comment #15 from Mark Thomas ---
I've applied the 9.0.x patch with some minor tweaks. Many thanks.
For reference, the minor tweaks were:
- removed trailing whitespace from one line to keep checkstyle happy
- made spacing around if/else blocks consistent with the rest of the code
- changed "if(!x){foo()}else{bar()}" to "if(x){bar()}else{foo()}"
I'll take a look at the 8.0.x patch next.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1678708 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/jasper/resources/LocalStrings.properties java/org/apache/jasper/servlet/TldScanner.java webapps/docs/changelog.xml
Author: markt Date: Mon May 11 09:48:53 2015 New Revision: 1678708 URL: http://svn.apache.org/r1678708 Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=56438 Add debug logging for TLD found/not-found in JARs, resource paths and directories. Based on a patch by VIN. Modified: tomcat/tc8.0.x/trunk/ (props changed) tomcat/tc8.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties tomcat/tc8.0.x/trunk/java/org/apache/jasper/servlet/TldScanner.java tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc8.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon May 11 09:48:53 2015 @@ -1 +1 @@ -/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892 ,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657 907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1 666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174 +/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1
[Bug 56438] If jar scan does not find context config or TLD config, log a message
https://bz.apache.org/bugzilla/show_bug.cgi?id=56438 --- Comment #16 from Mark Thomas --- 8.0.x was a straight back-port of the 9.0.x commit so that has been applied to. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56438] If jar scan does not find context config or TLD config, log a message
https://bz.apache.org/bugzilla/show_bug.cgi?id=56438 --- Comment #17 from VIN --- Thanks Mark. Below are the pending items to close this bug: 1) Adding debug log messages for both negative and positive matches of Pluggbility scan for all 3 versions(as trunk/8.0/7.0 are not having this) 2) Identify the default jars that can be added to JarsToSkip property and add them under all 3 versions. Please let me know if i miss any thing. Thanks, Pravallika(VIN) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/1207 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch tomcat/trunk] 1678690 Blamelist: kfujino Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
2015-05-11 10:56 GMT+02:00 Mark Thomas : > The catalyst for work this was reading RFC 7525 [1]. That got me > thinking about similar headers. > > In [1] HSTS support is a MUST and using it is a SHOULD. On that basis I > think 9.0.x should use it by default unless there is a really good > reason not to. > > While the other headers are not required by any RFC (as far as I am > aware) they are good for security so again I think they should be > enabled by default unless there is a good reason not to. > > Mark > > > [1] https://www.rfc-editor.org/rfc/rfc7525.txt > > Hm, there are other really "nice" security "features" that are done in filters in Tomcat and they are not enabled by default. Rémy
Re: Back-porting the new HttpHeaderSecurityFilter
On 11/05/2015 13:13, Rémy Maucherat wrote: > 2015-05-11 10:56 GMT+02:00 Mark Thomas : > >> The catalyst for work this was reading RFC 7525 [1]. That got me >> thinking about similar headers. >> >> In [1] HSTS support is a MUST and using it is a SHOULD. On that basis I >> think 9.0.x should use it by default unless there is a really good >> reason not to. >> >> While the other headers are not required by any RFC (as far as I am >> aware) they are good for security so again I think they should be >> enabled by default unless there is a good reason not to. >> >> Mark >> >> >> [1] https://www.rfc-editor.org/rfc/rfc7525.txt >> > Hm, there are other really "nice" security "features" that are done in > filters in Tomcat and they are not enabled by default. Which features are you thinking of and are you suggesting they should be enabled as well? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1678747 - /tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java
Author: markt
Date: Mon May 11 12:57:12 2015
New Revision: 1678747
URL: http://svn.apache.org/r1678747
Log:
Correctly return the buffer to the original state (was causing issues with the
SSLLabs server test)
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java?rev=1678747&r1=1678746&r2=1678747&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SNIExtractor.java Mon May 11
12:57:12 2015
@@ -52,6 +52,7 @@ public class SNIExtractor {
// Buffer is in write mode at this point. Record the current position
so
// the buffer state can be restored at the end of this method.
int pos = netInBuffer.position();
+int limit = netInBuffer.limit();
SNIResult result = SNIResult.NOT_PRESENT;
String sniValue = null;
try {
@@ -114,7 +115,7 @@ public class SNIExtractor {
this.result = result;
this.sniValue = sniValue;
// Whatever happens, return the buffer to its original state
-netInBuffer.limit(netInBuffer.capacity());
+netInBuffer.limit(limit);
netInBuffer.position(pos);
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Back-porting the new HttpHeaderSecurityFilter
2015-05-11 14:28 GMT+02:00 Mark Thomas : > Which features are you thinking of and are you suggesting they should be > enabled as well? > > I vote "not enabled" :) I'm not a big fan of these security features usually (just like when my browser decides I am stupid and must reject "fake" certs on my behalf). There is: - CorsFilter - CsrfPreventionFilter And there are also dos style filters and valves too: - CrawlerSessionManagerValve - StuckThreadDetectionValve - app servers usually add a valve or filter for JCA as well in that category Rémy
svn commit: r1678754 - in /tomcat/trunk: java/org/apache/tomcat/util/net/AprEndpoint.java java/org/apache/tomcat/util/net/SSLHostConfig.java webapps/docs/config/http.xml
Author: markt
Date: Mon May 11 13:38:49 2015
New Revision: 1678754
URL: http://svn.apache.org/r1678754
Log:
Switch the honorCipherOrder default to true and refactor the openSSL option
setting to set/clear each option as appropriate
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java
tomcat/trunk/webapps/docs/config/http.xml
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1678754&r1=1678753&r2=1678754&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Mon May 11
13:38:49 2015
@@ -414,72 +414,83 @@ public class AprEndpoint extends Abstrac
sm.getString("endpoint.apr.failSslContextMake"),
e);
}
-if (sslHostConfig.getInsecureRenegotiation()) {
-boolean legacyRenegSupported = false;
-try {
-legacyRenegSupported =
SSL.hasOp(SSL.SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION);
-if (legacyRenegSupported)
+boolean legacyRenegSupported = false;
+try {
+legacyRenegSupported =
SSL.hasOp(SSL.SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION);
+if (legacyRenegSupported)
+if (sslHostConfig.getInsecureRenegotiation()) {
SSLContext.setOptions(ctx,
SSL.SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION);
-} catch (UnsatisfiedLinkError e) {
-// Ignore
-}
-if (!legacyRenegSupported) {
-// OpenSSL does not support unsafe legacy
renegotiation.
-log.warn(sm.getString("endpoint.warn.noInsecureReneg",
- SSL.versionString()));
-}
+} else {
+SSLContext.clearOptions(ctx,
SSL.SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION);
+}
+} catch (UnsatisfiedLinkError e) {
+// Ignore
+}
+if (!legacyRenegSupported) {
+// OpenSSL does not support unsafe legacy renegotiation.
+log.warn(sm.getString("endpoint.warn.noInsecureReneg",
+ SSL.versionString()));
}
-// Set cipher order: client (default) or server
-if (sslHostConfig.getHonorCipherOrder()) {
-boolean orderCiphersSupported = false;
-try {
-orderCiphersSupported =
SSL.hasOp(SSL.SSL_OP_CIPHER_SERVER_PREFERENCE);
-if (orderCiphersSupported)
+// Use server's preference order for ciphers (rather than
+// client's)
+boolean orderCiphersSupported = false;
+try {
+orderCiphersSupported =
SSL.hasOp(SSL.SSL_OP_CIPHER_SERVER_PREFERENCE);
+if (orderCiphersSupported) {
+if (sslHostConfig.getHonorCipherOrder()) {
SSLContext.setOptions(ctx,
SSL.SSL_OP_CIPHER_SERVER_PREFERENCE);
-} catch (UnsatisfiedLinkError e) {
-// Ignore
-}
-if (!orderCiphersSupported) {
-// OpenSSL does not support ciphers ordering.
-
log.warn(sm.getString("endpoint.warn.noHonorCipherOrder",
- SSL.versionString()));
+} else {
+SSLContext.clearOptions(ctx,
SSL.SSL_OP_CIPHER_SERVER_PREFERENCE);
+}
}
+} catch (UnsatisfiedLinkError e) {
+// Ignore
+}
+if (!orderCiphersSupported) {
+// OpenSSL does not support ciphers ordering.
+log.warn(sm.getString("endpoint.warn.noHonorCipherOrder",
+ SSL.versionString()));
}
// Disable compression if requested
-if (sslHostConfig.getDisableCompression()) {
-boolean disableCompressionSupported = false;
-try {
-disableCompressionSupported =
SSL.hasOp(SSL.SSL_OP_NO_COMPRESSION);
-if (disableCompressionSupported)
+boolean disableCompressionSupported = false;
+try {
+
svn commit: r1678756 - in /tomcat/trunk: java/org/apache/tomcat/util/net/SSLHostConfig.java webapps/docs/config/http.xml
Author: markt
Date: Mon May 11 13:59:35 2015
New Revision: 1678756
URL: http://svn.apache.org/r1678756
Log:
Support SSLv2Hello by default.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java
tomcat/trunk/webapps/docs/config/http.xml
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java?rev=1678756&r1=1678755&r2=1678756&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java Mon May 11
13:59:35 2015
@@ -239,6 +239,7 @@ public class SSLHostConfig {
String trimmed = value.trim();
if (trimmed.length() > 0) {
if (input.trim().equalsIgnoreCase("all")) {
+protocols.add("SSLv2Hello");
protocols.add("TLSv1");
protocols.add("TLSv1.1");
protocols.add("TLSv1.2");
Modified: tomcat/trunk/webapps/docs/config/http.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=1678756&r1=1678755&r2=1678756&view=diff
==
--- tomcat/trunk/webapps/docs/config/http.xml (original)
+++ tomcat/trunk/webapps/docs/config/http.xml Mon May 11 13:59:35 2015
@@ -1230,7 +1230,7 @@
single protocol is specified it will not support
SSLv2Hello.
Note that all is an alias for
- TLSv1,TLSv1.1,TLSv1.2.
+ SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2.
Note that SSLv2 and SSLv3 are inherently
unsafe.
If not specified, the default value of all will be
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=8&rev2=9 * '''Stopped''': the instance OS process does not exist, and therefore the instance is not operating at all. + * '''Not Available''': This is a pseudo state that the manager applications (web and cli) show when a Grid Agent does not respond to requests for status in a timely manner. + * If possible it would be great to discern different sub cases of the Zoetic state, so to help the user to determine what's going on and tackle the case accordingly: * '''Starting''': The Tomcat instance process exists, and the instance is starting. It's not yet serving HTTP requests. * '''Stopping''': The Tomcat instance process exists, and the instance is stopping. It's no longer serving HTTP requests. * '''Unresponsive''': The Tomcat instance process exists, but the instance health isn't good, it's not responding to HTTP requests, or it's overwhelmed. It's not even responding to requests for status. + +* On second thoughts, these extra states can actually be discerned today with the current version of Tomcat, since the Grid Agents know all the trigger commands each local instance has received and can deduce (or make up) the sub case. If the Grid Agent is restarted, some kind of persistence of its state might be needed to "remember" what was going on before the Grid Agent was shut down, so to make an educated guess. + 1. Grid Agents communicate over unsecured TCP sockets, and assume communication security is enforced by the network architecture (segregated segments/VLans). 1. The "trigger"-type commands just deliver the corresponding signal to the instance's Grid Agent and returns right away, without waiting for the full operation to complete. It's kind of "fire and forget". The web user can keep on refreshing the the web interface to find out about the progress of the status of the Tomcat instances. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=9&rev2=10 * '''Stopping''': The Tomcat instance process exists, and the instance is stopping. It's no longer serving HTTP requests. -* '''Unresponsive''': The Tomcat instance process exists, but the instance health isn't good, it's not responding to HTTP requests, or it's overwhelmed. It's not even responding to requests for status. +* '''Unresponsive''': The Tomcat instance process exists, but the instance health isn't good, it's not responding to HTTP requests, or it's overwhelmed. It's not even responding to requests for status. This state is different from "Not Available" since in this case the Grid Agent IS active and responding, but the Tomcat instance itself is unresponsive. * On second thoughts, these extra states can actually be discerned today with the current version of Tomcat, since the Grid Agents know all the trigger commands each local instance has received and can deduce (or make up) the sub case. If the Grid Agent is restarted, some kind of persistence of its state might be needed to "remember" what was going on before the Grid Agent was shut down, so to make an educated guess. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat Grid - Write up open for discussion
I just finished writing the description of the Tomcat Grid as I see it, and I consider it ready for discussion. It's at: https://wiki.apache.org/tomcat/TomcatGridDiscussion So, how do we move from here? Thanks, Vlad - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
contribute to /manager
Hi, I would like to contribute to Tomcat Manager, maybe changing the layout or maybe trying to implement this requested feature ( https://bz.apache.org/bugzilla/show_bug.cgi?id=57701 ). Is it possible ? I am not sure the right way to help the project and if my contribution will be accepted. Thanks. []'s Fernando Boaglio - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57918] New: '127.0.0.1' is not recognized as an internal or external command, operable program or batch file.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57918 Bug ID: 57918 Summary: '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. Product: Tomcat 8 Version: 8.0.15 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: vibin...@gmail.com Installed Netbean 8.0.2 along with Apache Tomcat 8.0.15 , while trying to run a project , its showing error Starting Tomcat process... Waiting for Tomcat... Starting of Tomcat failed. C:\Users\..\NetBeansProjects\Test-Practice\nbproject\build-impl.xml:1150: Starting of Tomcat failed. BUILD FAILED (total time: 1 second) And Tomcat start failed showing , '127.0.0.1' is not recognized as an internal or external command, operable program or batch file. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57918] '127.0.0.1' is not recognized as an internal or external command, operable program or batch file.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57918 Vibin K Varghese changed: What|Removed |Added OS||All CC||vibin...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57918] '127.0.0.1' is not recognized as an internal or external command, operable program or batch file.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57918 Chuck Caldarale changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Chuck Caldarale --- Bugzilla is not a support forum; post your query on the Tomcat users' mailing list. Make sure you read this first: http://www.catb.org/~esr/faqs/smart-questions.html and then provide complete information, especially configuration settings. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by markt
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "TomcatGridDiscussion" page has been changed by markt: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=10&rev2=11 Comment: Add some initial comments The Grid Agents are Java processes installed and running on each machine that listen (on a configured port) for commands from a Grid Manager application (Web or CLI) and act upon them by interacting with the local Tomcat instances. No encryption is envisioned on the network channels, since all these machines are considered to be installed on a secured network segment (at least in prod). [Maybe we should reconsider this] + ''markt: I think this needs to be reconsidered.'' + - All Tomcat instances (including the Web Grid Managers), as well as the Grid Agents, are installed manually. The primary grid manager and all the agents are started manually too. + All Tomcat instances (including the Web Grid Managers), as well as the Grid Agents, are installed manually. The primary grid manager and all the agents are started manually too. - Once the Web Grid Manager is started up, machines and instances can be registered in it, so they can become manageable. No centralized (comprehensive) provisioning is envisioned until later versions of Tomcat Grid (see below). + Once the Web Grid Manager is started up, machines and instances can be registered in it, so they can become manageable. No centralized (comprehensive) provisioning is envisioned until later versions of Tomcat Grid (see below). The Grid Agents are processes that can also be managed. In particular, status can be obtained (and showed) from them, and basic operations (start/stop/kill) can be triggered on them. These operations are, however, heavily dependent on OS and OS capabilities (configuration, installed tools, etc.) and the infrastructure architecture (fire-walled machines, network VLans, etc). Collectively, Tomcat instances and Grid Agents are "services" since both can be managed. + ''markt: Managing the agents strikes me as making this significantly more complex. Operating systems have tools to ensure particular services are running and are restarted if they fail. What is the benefit of pulling this into this tool?'' + Later versions of the Grid include "collection" management. This allows to group subsets of services (Tomcat instances and Grid Agents), so they can be operated as whole. Each collection can include plain services, or other collections (recursively). Considering all the above, the following phases could be considered as a base line for the road map of the Tomcat Grid. + + ''markt: I'd like to see a little more high level architecture to steer development. For example, is there a common core of management functionality that we then wrap with a web-based GUI and a CLI? That would allow others to write other wrappers to plug this into other tools.'' == Phase 1 - Core Grid Operation == The first phase includes the most basic features, in order to provide a functioning and useful first version of the Grid. In particular, no Tomcat instances or Grid Agents automatic provisioning is considered, no configuration GUI (only pre-configured XML config files), no WAR deployments, no command-line interface, no complex grid operations, no secondary managers, and no collections. + + ''markt: This raises another architectural question. Wouldn't this be more scalable if agents were configured with the location of the primary manager and registered themselves? The manager could persist that registration so an agent would have to be explicitly removed if it was taken off-line permanently.'' Included features are: @@ -51, +59 @@ * '''trigger-start''': sends a start request to the Tomcat instance using the corresponding Grid Agent * '''trigger-stop''': sends a stop request to the Tomcat instance using the corresponding Grid Agent * '''trigger-kill''': sends a kill request to the Tomcat instance using the corresponding Grid Agent +* ''markt: A small thing. I think I'd prefer start/stop/kill/'' 1. A simple configuration file lists all the machines and their instances so the Grid knows where each instance resides. [This configuration file is probably in XML format] @@ -61, +70 @@ * OS calls for any OS related need. 1. It's assumed that a port will be accessible from each Grid Manager to each machine where the Grid Agents are serving. The firewall, if present must allow active server-type sockets on that port. + * ''markt: Another architectural question. Which end opens the connection, does it stay open and which protocol is used? For example, agents connect to Manager via WebSocket.'' 1. Multiple Grids (and Grid Agents) can be running on the same set (or subset) of machines. If that's the case, Tomcat instances, and G
Re: [VOTE] Release Apache Tomcat 7.0.62
2015-05-07 21:39 GMT+03:00 Violeta Georgieva : > > The proposed Apache Tomcat 7.0.62 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.62/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1043/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_62/ > > The proposed 7.0.62 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 7.0.62 Stable Tested Tomcat in OSGi environment - successful. Basic performance tests - successful. > Regards, > Violeta
[Bug 57918] '127.0.0.1' is not recognized as an internal or external command, operable program or batch file.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57918 Konstantin Kolinko changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Konstantin Kolinko --- *** This bug has been marked as a duplicate of bug 57053 *** -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57053] Tomcat 8.0.14 doesn't start with -Dhttp.nonProxyHosts
https://bz.apache.org/bugzilla/show_bug.cgi?id=57053 Konstantin Kolinko changed: What|Removed |Added CC||vibin...@gmail.com --- Comment #2 from Konstantin Kolinko --- *** Bug 57918 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: contribute to /manager
On 11/05/2015 16:41, Fernando Boaglio wrote: > Hi, > > I would like to contribute to Tomcat Manager, maybe changing the > layout or maybe trying to implement this requested feature ( > https://bz.apache.org/bugzilla/show_bug.cgi?id=57701 ). > > Is it possible ? Absolutely. > I am not sure the right way to help the project and if my contribution > will be accepted. The short answer is attach a patch in diff -u format to bug 57701. The longer answer is you'll need to get yourself set up with a development environment where you can build Tomcat to test your changes before you create the patch. Having a look at BUILDING.txt in the root of the svn repository for trunk (https://svn.apache.org/repos/asf/tomcat/trunk) is a good place to start and ask here of you need any help. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=11&rev2=12 ''markt: I think this needs to be reconsidered.'' + ''vlad: Sure. My take was to use unencrypted connections, since it's fast to implement for me and I don't know well how to implement a secured connection. Maybe we could even offer both options. Anyway, why do you consider we need an secured connection? In my experience, I've never needed them in dev/state/QA/test, and in prod the environment are isolated. Well... I guess there are other scenarios I haven't been exposed to.'' + All Tomcat instances (including the Web Grid Managers), as well as the Grid Agents, are installed manually. The primary grid manager and all the agents are started manually too. Once the Web Grid Manager is started up, machines and instances can be registered in it, so they can become manageable. No centralized (comprehensive) provisioning is envisioned until later versions of Tomcat Grid (see below). @@ -34, +36 @@ Collectively, Tomcat instances and Grid Agents are "services" since both can be managed. ''markt: Managing the agents strikes me as making this significantly more complex. Operating systems have tools to ensure particular services are running and are restarted if they fail. What is the benefit of pulling this into this tool?'' + + ''vlad: I agree that agents can run as daemons and be up all the time. However, I've seen many "robust" programs to have memory leaks and that for one reason or another stop working normally after some time. Maybe after a couple of days, or weeks, or months. Maybe it would be useful to restart them just before a critical operation such as a deployment. I agree that managing agent is more expensive since it requires the development and maintenance of multiple OS-dependent implementations.'' Later versions of the Grid include "collection" management. This allows to group subsets of services (Tomcat instances and Grid Agents), so they can be operated as whole. Each collection can include plain services, or other collections (recursively). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] New attachment added to page TomcatGridDiscussion
Dear Wiki user, You have subscribed to a wiki page "TomcatGridDiscussion" for change notification. An attachment has been added to that page by theimpaler. Following detailed information is available: Attachment name: Tomcat Grid software modules.png Attachment size: 25596 Attachment link: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=AttachFile&do=get&target=Tomcat+Grid+software+modules.png Page link: https://wiki.apache.org/tomcat/TomcatGridDiscussion - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "TomcatGridDiscussion" page has been changed by theimpaler:
https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=12&rev2=13
Considering all the above, the following phases could be considered as a base
line for the road map of the Tomcat Grid.
''markt: I'd like to see a little more high level architecture to steer
development. For example, is there a common core of management functionality
that we then wrap with a web-based GUI and a CLI? That would allow others to
write other wrappers to plug this into other tools.''
+
+ ''vlad: I would like to provide as much detail as you need, but I'm afraid I
still I don't quite understand exactly what you do you refer as the
architecture. Anyway, below is a general overview of the software modules and
their responsibilities.''
+
+ {{TomcatGridSoftwareModules.png}}
+
+ ''The modules are:
+
+ * '''Core module''': Shared logic to be used by all other modules.
+ * Core data types, such as "Machine", "Instance".
+ * Share core logic. For example, grid configuration file parsing/update.
+ * Defines the Grid Agent functions (as interfaces), but does not implement
them. These are used by all Managers modules.
+ * Common utility classes.
+ * Common exceptions.
+
+ * '''Web Manager module''': A JEE Web application that includes:
+ * Includes a simple Managing web GUI: web pages, navigation logic.
+ * Uses the Core module for functions such as:
+* Load Grid Configuration,
+* Interact with grid agents.
+
+ * '''CLI Manager module''': A java command-line program:
+ * Command-line interface: command parsing, text output.
+ * Uses the Core module for functions such as:
+* Load Grid Configuration,
+* Interact with grid agents.
+
+ * '''Any other Manager module''': Any future module that needs to connect to
Grid Agents to manage Tomcat instances.
+
+ * '''Grid Agent module''': Responds to Managers calls and controls local
Tomcat instances.
+ * Listen to Manager requests.
+ * Implements the Grid Agent interfaces.
+ * Includes the high-level interaction with Tomcat intances.
+ * Defines and uses the Tomcat Management Primitives (as interfaces), but
does not implement them.
+ * Receives content (deployables, grid configuration changes) and applies
them.
+
+ * '''Grid Agent Primitives for Linux''':
+ * Implements the Tomcat Management Primitives for Linux OS.
+
+ * '''Grid Agent Primitives for Windows''':
+ * Implements the Tomcat Management Primitives for Windows OS.
+
+ * '''Grid Agent Primitives for Mac''':
+ * Implements the Tomcat Management Primitives for Mac OS.
+
+ * '''Grid Agent Primitives for Other''':
+ * Implements the Tomcat Management Primitives for Other OS.
+
+
+ The executables themselves are comprised of several modules each that are
assembled during the build.
+ * The Grid Web Manager Executable (a WAR) includes:
+ * Core module
+ * Web Manager module
+ * The Grid CLI Manager Executable (a JAR) includes:
+ * Core module
+ * CLI Manager module
+ * The Grid Agent Executable (a JAR) includes:
+ * Core module
+ * Grid Agent module
+ * Grid Agent Primitives for Linux
+ * Grid Agent Primitives for Windows
+ * Grid Agent Primitives for Mac
+ * Grid Agent Primitives for Other
+ ''
== Phase 1 - Core Grid Operation ==
The first phase includes the most basic features, in order to provide a
functioning and useful first version of the Grid.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] New attachment added to page TomcatGridDiscussion
Dear Wiki user, You have subscribed to a wiki page "TomcatGridDiscussion" for change notification. An attachment has been added to that page by theimpaler. Following detailed information is available: Attachment name: TomcatGridSoftwareModules.png Attachment size: 25596 Attachment link: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=AttachFile&do=get&target=TomcatGridSoftwareModules.png Page link: https://wiki.apache.org/tomcat/TomcatGridDiscussion - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "TomcatGridDiscussion" page has been changed by theimpaler:
https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=13&rev2=14
''vlad: I would like to provide as much detail as you need, but I'm afraid I
still I don't quite understand exactly what you do you refer as the
architecture. Anyway, below is a general overview of the software modules and
their responsibilities.''
- {{TomcatGridSoftwareModules.png}}
+ {{attachment:TomcatGridSoftwareModules.png}}
''The modules are:
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "TomcatGridDiscussion" page has been changed by theimpaler:
https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=14&rev2=15
The Grid Agents are Java processes installed and running on each machine that
listen (on a configured port) for commands from a Grid Manager application (Web
or CLI) and act upon them by interacting with the local Tomcat instances. No
encryption is envisioned on the network channels, since all these machines are
considered to be installed on a secured network segment (at least in prod).
[Maybe we should reconsider this]
- ''markt: I think this needs to be reconsidered.''
+ ''__markt__: I think this needs to be reconsidered.''
- ''vlad: Sure. My take was to use unencrypted connections, since it's fast to
implement for me and I don't know well how to implement a secured connection.
Maybe we could even offer both options. Anyway, why do you consider we need an
secured connection? In my experience, I've never needed them in
dev/state/QA/test, and in prod the environment are isolated. Well... I guess
there are other scenarios I haven't been exposed to.''
+ ''__vlad__: Sure. My take was to use unencrypted connections, since it's fast
to implement for me and I don't know well how to implement a secured connection
:/ . Maybe we could even offer both options. Anyway, why do you consider we
need an secured connection? In my experience, I've never needed them in
dev/state/QA/test, and in prod the environment are isolated. Well... I guess
there are other scenarios I haven't been exposed to.''
All Tomcat instances (including the Web Grid Managers), as well as the Grid
Agents, are installed manually. The primary grid manager and all the agents are
started manually too.
@@ -35, +35 @@
Collectively, Tomcat instances and Grid Agents are "services" since both can
be managed.
- ''markt: Managing the agents strikes me as making this significantly more
complex. Operating systems have tools to ensure particular services are running
and are restarted if they fail. What is the benefit of pulling this into this
tool?''
+ ''__markt__: Managing the agents strikes me as making this significantly more
complex. Operating systems have tools to ensure particular services are running
and are restarted if they fail. What is the benefit of pulling this into this
tool?''
- ''vlad: I agree that agents can run as daemons and be up all the time.
However, I've seen many "robust" programs to have memory leaks and that for one
reason or another stop working normally after some time. Maybe after a couple
of days, or weeks, or months. Maybe it would be useful to restart them just
before a critical operation such as a deployment. I agree that managing agent
is more expensive since it requires the development and maintenance of multiple
OS-dependent implementations.''
+ ''__vlad__: I agree that agents can run as daemons and be up all the time.
However, I've seen many "robust" programs to have memory leaks and that for one
reason or another stop working normally after some time. Maybe after a couple
of days, or weeks, or months. Maybe it would be useful to restart them just
before a critical operation such as a deployment. I agree that managing agent
is more expensive since it requires the development and maintenance of multiple
OS-dependent implementations.''
Later versions of the Grid include "collection" management. This allows to
group subsets of services (Tomcat instances and Grid Agents), so they can be
operated as whole. Each collection can include plain services, or other
collections (recursively).
Considering all the above, the following phases could be considered as a base
line for the road map of the Tomcat Grid.
- ''markt: I'd like to see a little more high level architecture to steer
development. For example, is there a common core of management functionality
that we then wrap with a web-based GUI and a CLI? That would allow others to
write other wrappers to plug this into other tools.''
+ ''__markt__: I'd like to see a little more high level architecture to steer
development. For example, is there a common core of management functionality
that we then wrap with a web-based GUI and a CLI? That would allow others to
write other wrappers to plug this into other tools.''
- ''vlad: I would like to provide as much detail as you need, but I'm afraid I
still I don't quite understand exactly what you do you refer as the
architecture. Anyway, below is a general overview of the software modules and
their responsibilities.''
+ ''__vlad__: I would like to provide as much detail as you need, but I'm
afraid I still I don't quite understand exactly what you do you refer as the
architecture. Anyway, below is a general overview of the software modules and
their responsibilities.''
{{attachmen
Re: [VOTE] Release Apache Tomcat 6.0.44
On 8.5.2015 16:24, jean-frederic clere wrote: The proposed 6.0.44 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 6.0.44 Stable Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.7.0_79 and APR/native 1.1.33: - Tested TLS/SSL connectivity for BIO, NIO and APR connectors. Note: APR/native supports only TLS 1.0 by default. I needed to add attribute SSLProtocol to enable TLS 1.1/1.2. - Crawled all links (except /manager, /host-manager and /examples/async*). No broken links found, except links to JavaDocs. - Smoke tests of BIO, NIO and APR, with and without TLS, all passed. - Tested with several webapps that are in active development. -Ognjen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "TomcatGridDiscussion" by theimpaler
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=15&rev2=16 1. It's assumed that a port will be accessible from each Grid Manager to each machine where the Grid Agents are serving. The firewall, if present must allow active server-type sockets on that port. * ''__markt__: Another architectural question. Which end opens the connection, does it stay open and which protocol is used? For example, agents connect to Manager via WebSocket.'' - * ''__vlad__: I always considered the Grid Agent would would open a server NIO socket, to avoid using ephemereal ports. The Grid Agent is always listening, and the Managers connect when needed.'' + * ''__vlad__: I always considered the Grid Agent would would open a server NIO socket, to avoid using ephemereal ports. The Grid Agent is always listening, and the Managers connect when needed. In terms of protocol, it could be a ad-hoc one, specially developed for this tool, or use a well-known standard. I have ad-hoc one that I can use, but I'm open to suggestions.'' 1. Multiple Grids (and Grid Agents) can be running on the same set (or subset) of machines. If that's the case, Tomcat instances, and Grid Agents run on different ports for each grid. When multiple grids use the same machines they don't interfere with each other and can be operated simultaneously. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat Grid
2015-05-05 19:55 GMT+02:00 Alarcón Vladimir < vladimiralar...@yahoo.com.invalid>: > Hi, for a few months I was wondering about an extension for Tomcat but I'm > not sure if there would be interest from the part of the Tomcat team. > > It's about managing multiple Tomcat servers across multiple machines, from > one (or more) centralized location, something like a "Grid Admin". Anyway, > the thing is that when you have many Tomcat servers, it could be useful to > perform basic operations from a web or command-line interface, so to start, > stop, restart, and (sometimes) kill Tomcat servers. > > My work includes developing web applications and also managing production > deployments for clusters of small clusters of 2 servers to clusters of 70 > servers, and when you have that many, it's a pain in the neck to manage > them one by one. > > I think I can write a basic proof of concept, but I would like to find out > if it's worth it or not. > > Ok, so I am casually reading the wiki. This started with a simple initial proposition I guess, but now it is probably a much bigger project that Tomcat itself. Another caveat is that this is a lot of infrastructure to deploy for the admin/user, who also probably needs to monitor the rest of his stuff, so usually this sort of tool also monitors the JVMs, the OSes, the front end proxys, the DBs, etc etc etc. I had to have a look at some point at the relevant open source project Red Hat is doing ( http://rhq-project.github.io/rhq/ ), and I found it was very complex. Its architecture looks similar to what I see in the wiki now. There are probably many more projects like that out there, but since I am not an admin, I don't really care that much :) So, good luck with this Tomcat specific project if you decide to go for it ! IMO to provide some good value it would have to focus on easy deployment and config, taking advantage of being a specialized tool. Rémy
