svn commit: r1643761 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java

[violetagg]

Author: violetagg
Date: Mon Dec  8 08:20:35 2014
New Revision: 1643761

URL: http://svn.apache.org/r1643761
Log:
Close the InputStream after retrieving the last modification time from 
URLConnection.

Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java

Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1643761&r1=1643760&r2=1643761&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Mon Dec  8 
08:20:35 2014
@@ -1460,20 +1460,42 @@ public class ContextConfig implements Li
 long hostTimeStamp = 0;
 
 if (globalWebXml != null) {
+URLConnection uc = null;
 try {
 URL url = new URL(globalWebXml.getSystemId());
-globalTimeStamp = url.openConnection().getLastModified();
+uc = url.openConnection();
+globalTimeStamp = uc.getLastModified();
 } catch (IOException e) {
 globalTimeStamp = -1;
+} finally {
+if (uc != null) {
+try {
+uc.getInputStream().close();
+} catch (IOException e) {
+ExceptionUtils.handleThrowable(e);
+globalTimeStamp = -1;
+}
+}
 }
 }
 
 if (hostWebXml != null) {
+URLConnection uc = null;
 try {
 URL url = new URL(hostWebXml.getSystemId());
-hostTimeStamp = url.openConnection().getLastModified();
+uc = url.openConnection();
+hostTimeStamp = uc.getLastModified();
 } catch (IOException e) {
 hostTimeStamp = -1;
+} finally {
+if (uc != null) {
+try {
+uc.getInputStream().close();
+} catch (IOException e) {
+ExceptionUtils.handleThrowable(e);
+globalTimeStamp = -1;
+}
+}
 }
 }
 



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643764 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml

[violetagg]

Author: violetagg
Date: Mon Dec  8 08:51:47 2014
New Revision: 1643764

URL: http://svn.apache.org/r1643764
Log:
Merged revision 1643761 from tomcat/trunk:
Close the InputStream after retrieving the last modification time from 
URLConnection.

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 08:51:47 2014
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734
+/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1643764&r1=1643763&r2=1643764&view=diff
==
--- tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java 
(original)
+++ tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java 
Mon Dec  8 08:51:47 2014
@@ -1460,20 +1460,42 @@ public class ContextConfig implements Li
 long hostTimeStamp = 0;
 
 if (globalWebXml != null) {
+URLConnection uc = null;
 try {
 URL url = new URL(globalWebXml.getSystemId());
-globalTimeStamp = url.openConnection().getLastModified();
+uc = url.openConnection();
+globalTimeStamp = uc.getLastModified();
 } catch (IOException e) {
 globalTimeStamp = -1;
+} finally {
+if (uc != null) {
+try {
+uc.getInputStream().close();
+} catch (IOException e) {
+ExceptionUtils.handleThrowable(e);
+globalTimeStamp = -1;
+}
+}
 }
 }
 
 if (hostWebXml != null) {
+URLConnection uc = null;
 try {
 URL url = new URL(hostWebXml.getSystemId());
-hostTimeStamp = url.openConnection().getLastModified();
+uc = url.openConnection();
+hostTimeStamp = uc.getLastModified();
 } catch (IOException e) {
 hostTimeStamp = -1;
+} finally {
+if (uc != null) {
+try {
+uc.getInputStream().close();
+} catch (IOException e) {
+ExceptionUtils.handleThrowable(e);
+globalTimeStamp = -1;
+}
+}
 }
 }
 

Modified: tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml?rev=1643764&r1=1643763&r2=1643764&view=diff
==
--- tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Mon Dec  8 08:51:47 2014
@@ -134,6 +134,10 @@
 Remove the obsolete jndi protocol usage from the scanning
 process performed by StandardJarScanner. (violetagg)
   
+  
+Prevent file descriptors leak and ensure that files are closed after
+retrieving the last modification time. (violetagg)
+  
 
   
 

svn commit: r1643765 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml

[violetagg]

Author: violetagg
Date: Mon Dec  8 08:53:46 2014
New Revision: 1643765

URL: http://svn.apache.org/r1643765
Log:
Merged revision 1643761 from tomcat/trunk:
Close the InputStream after retrieving the last modification time from 
URLConnection.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc7.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 08:53:46 2014
@@ -1,2 +1,2 @@
 
/tomcat/tc8.0.x/trunk:1636525,1637336,1637685,1637709,1638726,1640089,1640276,1640349,1640363,1640366,1640642,1640672,1640674,1640689,1640884,1641001,1641065,1641067,1641375,1641638,1641723,1641726,1641729-1641730,1641736,1641988,1642669-1642670,1642698,1642701,1643205,1643215,1643217,1643230,1643232,1643273,1643285,1643329-1643330,1643511,1643513,1643521,1643539,1643571,1643581-1643582,1643635,1643655,1643738
-/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177785-1177980,1178006-1180720,1180722-1183094,1183096-1187753,1187755,1187775,1187801,1187806,1187809,1187826-1188312,1188314-1188401,1188646-1188840,1188842-1190176,1190178-1195223,1195225-1195953,1195955,1195957-1201238,1201240-1203345,1203347-1206623,1206625-1208046,1208073,1208096,1208114,1208145,1208772,1209194-1212125,1212127-1220291,1220293,1220295-1221321,1221323-1222329,1222332-1222401,1222405-1222795,1222850-1222950,1222969-1225326,1225328-1225463,1225465,1225627,1225629-1226534,1226536-1228908,1228911-1228923,1228927-1229532,1229534-1230766,1230768-1231625,1231627-1233414,1233419-1235207,1235209-1237425,1237427,1237429-1237977,1237981,1237985,1237995,1238070,1238073,1239024-1239048,1239050-1239062,1239135,1239256,1239258-1239485,1239785-1240046,1240101,1240106,1240109,1240112,1240114
 
,1240116,1240118,1240121,1240329,1240474-1240850,1240857,1241087,1241160,1241408-1241822,1241908-1241909,1241912-1242110,1242371-1292130,1292134-1292458,1292464-1292670,1292672-1292776,1292780-1293392,1293397-1297017,1297019-1297963,1297965-1299820,1300108,1300111-1300460,1300520-1300948,1300997,1301006,1301280,1302332,1302348,1302608-1302610,1302649,1302837,1303138,1303163,1303338,1303521,1303587,1303698,1303803,1303852,1304011,1304035,1304037,1304135,1304249,1304253,1304260,1304271,1304275,1304468,1304895,1304930-1304932,1305194,1305943,1305965,1306556,1306579-1306580,1307084,1307310,1307511-1307512,1307579,1307591,1307597,1310636,1310639-1310640,1310642,1310701,1311212,1311995,1327617,1327670,1331766,1333161,1333173,1333827,1334787,1335026,1335257,1335547,1335692,1335711,1335731,1336515,1336813,1336864,1336868,1336884,1337419,1337426,1337546,1337572,1337591-1337595,1337643,1337707,1337719,1337734,1337741,1337745,1338151-1338154,1338178,1342027,1342029,1342315,1342320,1342476,1342
 
498,1342503,1342717,1342795,1342805,1343044-1343046,1343335,1343394,1343400,1343629,1343708,1343718,1343895,1344063,1344068,1344250,1344266,1344515,1344528,1344612,1344629,1344725,1344868,1344890,1344893,1344896,1344901,1345020,1345029,1345039,1345287-1345290,1345294,1345309,1345325,1345357,1345367,1345579-1345580,1345582,1345688,1345699,1345704,1345731-1345732,1345737,1345744,1345752,1345754,1345779,1345781,1345846,1346107,1346365,1346376,1346404,1346510,1346514,1346519,1346581,1346635,1346644,1346683,1346794,1346885,1346932,1347034,1347047,1347087,1347108-1347109,1347583,1347737,1348105,1348357,1348398,1348425,1348461-1348495,1348498,1348752,1348762,1348772,1348776,1348859,1348968,1348973,1348989,1349007,1349237,1349298,1349317,1349410,1349473,1349539,1349879,1349887,1349893,1349922,1349984,1350124,1350241,1350243,1350294-1350295,1350299,1350864,1350900,1351010,1351054,1351056,1351068,1351134-1351135,1351148,1351259,1351604,1351636-1351640,1351991,1351993,1352011,1352056,1352059,1
 
352661,1352663,1352788,1352799,1353087,1353125,1353240,1353261,1353414,1353468,1353501,1353581,1353708,1354137,1354170,1354197,1354255,1354362,1354375,1354469,1354664,1354685,1354817,1354847,1354856,1355726,1355810,1356006-1356007,1356014,1356045,1356125,1356422,1356505,1356898,1357042,1357401,1357407,1358586,1358590,1358612-1358613,1359102,1359340,1359981,1360059,1360455,1360460,1360838,1360847,1360892,1360942,1361263,1361430,1361754-1361755,1361762,1361769,1361772,1361962,1361982,1361985,1361991,1364141,1364149,1364411-1364412,1364448,1366708,1366720,1366729,1366734,1366910,1366945,1366953,1366959,1367214,1370346,1370364,1370373,1370386,1370473,1370537,1370549,1370553,1370879,1370916,1370958,1370960,1370973,1371017,1371283,1371336,1371620,1371812,1371823,1371896,1371976,1371978,1371995,1371999,1372131,1372152,1372156,1372390,1373003,1373080,1373142,1373488,1373578,1373618,1373622,1373666,1373985,1373987,1373990,1373993,1374000,1374019,13

svn commit: r1643766 - /tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

[violetagg]

Author: violetagg
Date: Mon Dec  8 09:04:56 2014
New Revision: 1643766

URL: http://svn.apache.org/r1643766
Log:
Extract several "protected" methods in order to make StandardRoot easier for 
extending.

Modified:
tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

Modified: tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643766&r1=1643765&r2=1643766&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java Mon 
Dec  8 09:04:56 2014
@@ -457,6 +457,10 @@ public class StandardRoot extends Lifecy
 return postResources.toArray(new WebResourceSet[0]);
 }
 
+protected WebResourceSet[] getClassResources() {
+return classResources.toArray(new WebResourceSet[0]);
+}
+
 @Override
 public void setAllowLinking(boolean allowLinking) {
 this.allowLinking = allowLinking;
@@ -633,9 +637,7 @@ public class StandardRoot extends Lifecy
 
 cacheJmxName = register(cache, getObjectNameKeyProperties() + 
",name=Cache");
 
-// Ensure support for jar:war:file:/ URLs will be available (required
-// for resource JARs in packed WAR files).
-TomcatURLStreamHandlerFactory.register();
+registerURLStreamHandlerFactory();
 
 if (context == null) {
 throw new IllegalStateException(
@@ -649,29 +651,17 @@ public class StandardRoot extends Lifecy
 }
 }
 
+protected void registerURLStreamHandlerFactory() {
+// Ensure support for jar:war:file:/ URLs will be available (required
+// for resource JARs in packed WAR files).
+TomcatURLStreamHandlerFactory.register();
+}
+
 @Override
 protected void startInternal() throws LifecycleException {
-String docBase = context.getDocBase();
-
 mainResources.clear();
 
-if (docBase == null) {
-main = new EmptyResourceSet(this);
-} else {
-File f = new File(docBase);
-if (!f.isAbsolute()) {
-f = new File(((Host)context.getParent()).getAppBaseFile(), 
f.getPath());
-}
-if (f.isDirectory()) {
-main = new DirResourceSet(this, "/", f.getAbsolutePath(), "/");
-} else if(f.isFile() && docBase.endsWith(".war")) {
-main = new JarResourceSet(this, "/", f.getAbsolutePath(), "/");
-} else {
-throw new IllegalArgumentException(
-sm.getString("standardRoot.startInvalidMain",
-f.getAbsolutePath()));
-}
-}
+main = createMainResourceSet();
 
 mainResources.add(main);
 
@@ -694,6 +684,31 @@ public class StandardRoot extends Lifecy
 setState(LifecycleState.STARTING);
 }
 
+protected WebResourceSet createMainResourceSet() {
+String docBase = context.getDocBase();
+
+WebResourceSet mainResourceSet;
+if (docBase == null) {
+mainResourceSet = new EmptyResourceSet(this);
+} else {
+File f = new File(docBase);
+if (!f.isAbsolute()) {
+f = new File(((Host)context.getParent()).getAppBaseFile(), 
f.getPath());
+}
+if (f.isDirectory()) {
+mainResourceSet = new DirResourceSet(this, "/", 
f.getAbsolutePath(), "/");
+} else if(f.isFile() && docBase.endsWith(".war")) {
+mainResourceSet = new JarResourceSet(this, "/", 
f.getAbsolutePath(), "/");
+} else {
+throw new IllegalArgumentException(
+sm.getString("standardRoot.startInvalidMain",
+f.getAbsolutePath()));
+}
+}
+
+return mainResourceSet;
+}
+
 @Override
 protected void stopInternal() throws LifecycleException {
 for (ArrayList list : allResources) {



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 57324] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with "keepalive" connections

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57324

--- Comment #3 from Vamsi Krishna  ---
I am attaching traces from my wireshark analysis. It captures 3 request
response cycles. Please proceed to my notes at the end after the trace.

**
1) POST /someresource/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol
4.0.30319.18444)
Content-Type: text/xml; charset=utf-8
Authorization: Basic VALIDCREDENTIALS=
Host: serveraddress
Content-Length: 327
Expect: 100-continue

HTTP/1.1 100 Continue



HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Content-Length: 424
Date: Mon, 08 Dec 2014 08:47:08 GMT




2) POST /someotherresource/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol
4.0.30319.18444)
Content-Type: text/xml; charset=utf-8
Host: serveraddress
Content-Length: 331
Expect: 100-continue

HTTP/1.1 100 Continue



HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm="blah"
WWW-Authenticate: blah realm="blah"
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 951
Date: Mon, 08 Dec 2014 08:47:09 GMT



3) POST /someotherresource/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol
4.0.30319.18444)
Content-Type: text/xml; charset=utf-8
Authorization: Basic VALIDCREDENTIALS=
Host: 10.71.65.156
Content-Length: 331
Expect: 100-continue


***

* In the above trace, my client made two webservice calls in a total of 3
reply-request cycles. The first request marked with 1) was straight forward and
completed successfully with Expect100continue behavior.

* The second webservice call was split into two cycles by .NET and its
unnecessary optimization. Without the Application Developers clear intent to do
so, .NET sent the second request without any credentials triggering a 401
response from server. However, according to RFC
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 

"401" response does give a chance for client to resubmit its request with
proper credentials.

* The third request number 3) in the trace is .NET trial at doing the same i.e
resubmitting the second request with credentials.

Because of the change done by Tomcat, the client does not get a chance and the
socket is closed by Tomcat. 

The problem is severe because , in all of this, Application Developer does not
get any control from .NET and Client code simply breaks with an exception
because .NET did not check the health of socket before making request 3) in the
above trace.

Agreed there is a lot of problem here in .NET and we can reach out to
Microsoft, but going and patching each and every client out there is going to
be really costly. Also, it can be argued that with this new change, Tomcat is
not giving opportunity to client to resubmit the 401 challenged response, so it
may be a violation of RFC. 

Also, my traces are not consistent with the original issue reported so I need
someone to investigate further. The original issue may be something happening
only when there is an intermediate node involved. 

I may not be an expert in all of this, but feel there is something Tomcat can
do about all of this. I have also reopened the bug only to demonstrate my
point, but not to violate the process in the forum. If it is still not
convincing, please go ahead and close the case.

-- 
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 57326] New: AsyncContextImpl doesn't allow AsyncListener to re-register themselves when firing onStartAsync

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57326

Bug ID: 57326
   Summary: AsyncContextImpl doesn't allow AsyncListener to
re-register themselves when firing onStartAsync
   Product: Tomcat 7
   Version: trunk
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: efou...@voyages-sncf.com

According to the official Java EE Javadoc (cf.
https://docs.oracle.com/javaee/7/api/javax/servlet/AsyncListener.html#onStartAsync%28javax.servlet.AsyncEvent%29),
AsyncListeners should be allowed to re-register themselves when the event
"onStartAsync" is started : "This AsyncListener will not receive any events
related to the new asynchronous cycle unless it registers itself (via a call to
AsyncContext.addListener(javax.servlet.AsyncListener)) with the AsyncContext
that is delivered as part of the given AsyncEvent.".
In tomcat 7.0.x, the actual implementation prevents this behavior since the
listeners list is cleared *after* firing the event (cf.
AdyncContextImpl.java:366). If the list was cleared before firing the event,
listeners would be able to re-register themselves if needed.

-- 
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: r1643768 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/webresources/StandardRoot.java webapps/docs/changelog.xml

[violetagg]

Author: violetagg
Date: Mon Dec  8 09:28:22 2014
New Revision: 1643768

URL: http://svn.apache.org/r1643768
Log:
Merged revision 1643766 from tomcat/trunk:
Extract several "protected" methods in order to make StandardRoot easier for 
extending.

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 09:28:22 2014
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761
+/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643768&r1=1643767&r2=1643768&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
Mon Dec  8 09:28:22 2014
@@ -457,6 +457,10 @@ public class StandardRoot extends Lifecy
 return postResources.toArray(new WebResourceSet[0]);
 }
 
+protected WebResourceSet[] getClassResources() {
+return classResources.toArray(new WebResourceSet[0]);
+}
+
 @Override
 public void setAllowLinking(boolean allowLinking) {
 this.allowLinking = allowLinking;
@@ -633,9 +637,7 @@ public class StandardRoot extends Lifecy
 
 cacheJmxName = register(cache, getObjectNameKeyProperties() + 
",name=Cache");
 
-// Ensure support for jar:war:file:/ URLs will be available (required
-// for resource JARs in packed WAR files).
-TomcatURLStreamHandlerFactory.register();
+registerURLStreamHandlerFactory();
 
 if (context == null) {
 throw new IllegalStateException(
@@ -649,29 +651,17 @@ public class StandardRoot extends Lifecy
 }
 }
 
+protected void registerURLStreamHandlerFactory() {
+// Ensure support for jar:war:file:/ URLs will be available (required
+// for resource JARs in packed WAR files).
+TomcatURLStreamHandlerFactory.register();
+}
+
 @Override
 protected void startInternal() throws LifecycleException {
-String docBase = context.getDocBase();
-
 mainResources.clear();
 
-if (docBase == null) {
-main = new EmptyResourceSet(this);
-} else {
-File f = new File(docBase);
-if (!f.isAbsolute()) {
-f = new File(((Host)context.getParent()).getAppBaseFile(), 
f.getPath());
-}
-if (f.isDirectory()) {
-main = new DirResourceSet(this, "/", f.getAbsolutePath(), "/");
-} else if(f.isFile() && docBase.endsWith(".war")) {
-main = new JarResourceSet(this, "/", f.getAbsolutePath(), "/");
-} else {
-throw new IllegalArgumentException(
-sm.getString("standardRoot.startInvalidMain",
-f.getAbsolutePath()));
-}
-}
+main = createMainResourceSet();
 
 mainResources.add(main);
 
@@ -694,6 +684,31 @@ public class StandardRoot extends Lifecy
 setState(LifecycleState.STARTING);
 }
 
+protected WebResourceSet createMain

svn commit: r1643770 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java

[violetagg]

Author: violetagg
Date: Mon Dec  8 09:41:28 2014
New Revision: 1643770

URL: http://svn.apache.org/r1643770
Log:
Merged revision 1643675 from tomcat/trunk:
It is not necessary to handle MalformedURLException separately as it extends 
IOException.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java

Propchange: tomcat/tc7.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 09:41:28 2014
@@ -1,2 +1,2 @@
 
/tomcat/tc8.0.x/trunk:1636525,1637336,1637685,1637709,1638726,1640089,1640276,1640349,1640363,1640366,1640642,1640672,1640674,1640689,1640884,1641001,1641065,1641067,1641375,1641638,1641723,1641726,1641729-1641730,1641736,1641988,1642669-1642670,1642698,1642701,1643205,1643215,1643217,1643230,1643232,1643273,1643285,1643329-1643330,1643511,1643513,1643521,1643539,1643571,1643581-1643582,1643635,1643655,1643738
-/tomcat/trunk:1156115-1157160,1157162-1157859,1157862-1157942,1157945-1160347,1160349-1163716,1163718-1166689,1166691-1174340,1174342-1175596,1175598-1175611,1175613-1175932,1175934-1177783,1177785-1177980,1178006-1180720,1180722-1183094,1183096-1187753,1187755,1187775,1187801,1187806,1187809,1187826-1188312,1188314-1188401,1188646-1188840,1188842-1190176,1190178-1195223,1195225-1195953,1195955,1195957-1201238,1201240-1203345,1203347-1206623,1206625-1208046,1208073,1208096,1208114,1208145,1208772,1209194-1212125,1212127-1220291,1220293,1220295-1221321,1221323-1222329,1222332-1222401,1222405-1222795,1222850-1222950,1222969-1225326,1225328-1225463,1225465,1225627,1225629-1226534,1226536-1228908,1228911-1228923,1228927-1229532,1229534-1230766,1230768-1231625,1231627-1233414,1233419-1235207,1235209-1237425,1237427,1237429-1237977,1237981,1237985,1237995,1238070,1238073,1239024-1239048,1239050-1239062,1239135,1239256,1239258-1239485,1239785-1240046,1240101,1240106,1240109,1240112,1240114
 
,1240116,1240118,1240121,1240329,1240474-1240850,1240857,1241087,1241160,1241408-1241822,1241908-1241909,1241912-1242110,1242371-1292130,1292134-1292458,1292464-1292670,1292672-1292776,1292780-1293392,1293397-1297017,1297019-1297963,1297965-1299820,1300108,1300111-1300460,1300520-1300948,1300997,1301006,1301280,1302332,1302348,1302608-1302610,1302649,1302837,1303138,1303163,1303338,1303521,1303587,1303698,1303803,1303852,1304011,1304035,1304037,1304135,1304249,1304253,1304260,1304271,1304275,1304468,1304895,1304930-1304932,1305194,1305943,1305965,1306556,1306579-1306580,1307084,1307310,1307511-1307512,1307579,1307591,1307597,1310636,1310639-1310640,1310642,1310701,1311212,1311995,1327617,1327670,1331766,1333161,1333173,1333827,1334787,1335026,1335257,1335547,1335692,1335711,1335731,1336515,1336813,1336864,1336868,1336884,1337419,1337426,1337546,1337572,1337591-1337595,1337643,1337707,1337719,1337734,1337741,1337745,1338151-1338154,1338178,1342027,1342029,1342315,1342320,1342476,1342
 
498,1342503,1342717,1342795,1342805,1343044-1343046,1343335,1343394,1343400,1343629,1343708,1343718,1343895,1344063,1344068,1344250,1344266,1344515,1344528,1344612,1344629,1344725,1344868,1344890,1344893,1344896,1344901,1345020,1345029,1345039,1345287-1345290,1345294,1345309,1345325,1345357,1345367,1345579-1345580,1345582,1345688,1345699,1345704,1345731-1345732,1345737,1345744,1345752,1345754,1345779,1345781,1345846,1346107,1346365,1346376,1346404,1346510,1346514,1346519,1346581,1346635,1346644,1346683,1346794,1346885,1346932,1347034,1347047,1347087,1347108-1347109,1347583,1347737,1348105,1348357,1348398,1348425,1348461-1348495,1348498,1348752,1348762,1348772,1348776,1348859,1348968,1348973,1348989,1349007,1349237,1349298,1349317,1349410,1349473,1349539,1349879,1349887,1349893,1349922,1349984,1350124,1350241,1350243,1350294-1350295,1350299,1350864,1350900,1351010,1351054,1351056,1351068,1351134-1351135,1351148,1351259,1351604,1351636-1351640,1351991,1351993,1352011,1352056,1352059,1
 
352661,1352663,1352788,1352799,1353087,1353125,1353240,1353261,1353414,1353468,1353501,1353581,1353708,1354137,1354170,1354197,1354255,1354362,1354375,1354469,1354664,1354685,1354817,1354847,1354856,1355726,1355810,1356006-1356007,1356014,1356045,1356125,1356422,1356505,1356898,1357042,1357401,1357407,1358586,1358590,1358612-1358613,1359102,1359340,1359981,1360059,1360455,1360460,1360838,1360847,1360892,1360942,1361263,1361430,1361754-1361755,1361762,1361769,1361772,1361962,1361982,1361985,1361991,1364141,1364149,1364411-1364412,1364448,1366708,1366720,1366729,1366734,1366910,1366945,1366953,1366959,1367214,1370346,1370364,1370373,1370386,1370473,1370537,1370549,1370553,1370879,1370916,1370958,1370960,1370973,1371017,1371283,1371336,1371620,1371812,1371823,1371896,1371976,1371978,1371995,1371999,1372131,1372152,1372156,1372390,1373003,1373080,1373142,1373488,1373578,1373618,1373622,1373666,1373985,1373987,1373990,1373993,1374000,1374019,1374086,1374823,1376994,1377078,1377292,137731
 
1

[jira] [Created] (MTOMCAT-290) Parallel deployment - Support version in war file name when using run-war goal

[Olivier Roger (JIRA)]

Olivier Roger created MTOMCAT-290:
-

 Summary: Parallel deployment - Support version in war file name 
when using run-war goal
 Key: MTOMCAT-290
 URL: https://issues.apache.org/jira/browse/MTOMCAT-290
 Project: Apache Tomcat Maven Plugin
  Issue Type: Improvement
  Components: tomcat7
Affects Versions: 2.2
 Environment: maven tomcat7
Reporter: Olivier Roger
Assignee: Olivier Lamy (*$^¨%`£)


When using the tomcat7:run-war goal, the context is created based on the *path* 
configuration parameter.

To use parallel deployment 
(http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) I 
usually append the timestamp to the path as shown below:

org.apache.tomcat.maven
tomcat7-maven-plugin

/myWar##${maven.build.timestamp}

This works perfectly when deploying (tomcat7:deploy-only) the war since Tomcat 
detect the ## and separate the context from the version.

However there the same process is not applied when running the war 
(tomocat7:run-war) the ## characters are URL encoded as %13%13 and the version 
(=timestamp) is in the resulting context.

Usually all character should be URL encoded as it is done as the moment, but 
this case of parallel deployement might be an exception. (feature was 
introducted in tomcat7).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Updated] (MTOMCAT-290) Parallel deployment - Support version in war file name when using run-war goal

[Olivier Roger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MTOMCAT-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Roger updated MTOMCAT-290:
--
Description: 
When using the tomcat7:run-war goal, the context is created based on the *path* 
configuration parameter.

To use parallel deployment 
(http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) I 
usually append the timestamp to the path as shown below:

org.apache.tomcat.maven
tomcat7-maven-plugin

/myWar##${maven.build.timestamp}

This works perfectly when deploying (tomcat7:deploy-only) the war since Tomcat 
detect the ## and separate the context from the version.

However there the same process is not applied when running the war 
(tomocat7:run-war) the *##* characters are URL encoded as *%13%13* and the 
version (=timestamp) is in the resulting context.

Usually all character should be URL encoded as it is done as the moment, but 
this case of parallel deployement might be an exception. (feature was 
introducted in tomcat7).

  was:
When using the tomcat7:run-war goal, the context is created based on the *path* 
configuration parameter.

To use parallel deployment 
(http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) I 
usually append the timestamp to the path as shown below:

org.apache.tomcat.maven
tomcat7-maven-plugin

/myWar##${maven.build.timestamp}

This works perfectly when deploying (tomcat7:deploy-only) the war since Tomcat 
detect the ## and separate the context from the version.

However there the same process is not applied when running the war 
(tomocat7:run-war) the ## characters are URL encoded as %13%13 and the version 
(=timestamp) is in the resulting context.

Usually all character should be URL encoded as it is done as the moment, but 
this case of parallel deployement might be an exception. (feature was 
introducted in tomcat7).

   Priority: Minor  (was: Major)

> Parallel deployment - Support version in war file name when using run-war goal
> --
>
> Key: MTOMCAT-290
> URL: https://issues.apache.org/jira/browse/MTOMCAT-290
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Improvement
>  Components: tomcat7
>Affects Versions: 2.2
> Environment: maven tomcat7
>Reporter: Olivier Roger
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: maven, parallel-deployment, run-war
>
> When using the tomcat7:run-war goal, the context is created based on the 
> *path* configuration parameter.
> To use parallel deployment 
> (http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) 
> I usually append the timestamp to the path as shown below:
>   org.apache.tomcat.maven
>   tomcat7-maven-plugin
>   
>   /myWar##${maven.build.timestamp}
> This works perfectly when deploying (tomcat7:deploy-only) the war since 
> Tomcat detect the ## and separate the context from the version.
> However there the same process is not applied when running the war 
> (tomocat7:run-war) the *##* characters are URL encoded as *%13%13* and the 
> version (=timestamp) is in the resulting context.
> Usually all character should be URL encoded as it is done as the moment, but 
> this case of parallel deployement might be an exception. (feature was 
> introducted in tomcat7).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643814 - in /tomcat/trunk/java/org/apache/tomcat/dbcp/pool2: ./ impl/BaseGenericObjectPool.java impl/DefaultPooledObject.java impl/LinkedBlockingDeque.java

[markt]

Author: markt
Date: Mon Dec  8 13:25:58 2014
New Revision: 1643814

URL: http://svn.apache.org/r1643814
Log:
Update fork of Apache Commons Pool2 to latest trunk to pick up fixes including 
one for a potential infinite loop.

Modified:
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/   (props changed)

tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/DefaultPooledObject.java
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java

Propchange: tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 13:25:58 2014
@@ -1 +1 @@
-/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2:1593516-1627271
+/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2:1593516-1643813

Modified: 
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java?rev=1643814&r1=1643813&r2=1643814&view=diff
==
--- 
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java 
(original)
+++ 
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java 
Mon Dec  8 13:25:58 2014
@@ -111,8 +111,7 @@ public abstract class BaseGenericObjectP
 private final StatsStore activeTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
 private final StatsStore idleTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
 private final StatsStore waitTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
-private final Object maxBorrowWaitTimeMillisLock = new Object();
-private volatile long maxBorrowWaitTimeMillis = 0; // 
@GuardedBy("maxBorrowWaitTimeMillisLock")
+private final AtomicLong maxBorrowWaitTimeMillis = new AtomicLong(0L);
 private volatile SwallowedExceptionListener swallowedExceptionListener = 
null;
 
 
@@ -809,7 +808,7 @@ public abstract class BaseGenericObjectP
  * @return maximum wait time in milliseconds since the pool was created
  */
 public final long getMaxBorrowWaitTimeMillis() {
-return maxBorrowWaitTimeMillis;
+return maxBorrowWaitTimeMillis.get();
 }
 
 /**
@@ -873,11 +872,15 @@ public abstract class BaseGenericObjectP
 borrowedCount.incrementAndGet();
 idleTimes.add(p.getIdleTimeMillis());
 waitTimes.add(waitTime);
-synchronized (maxBorrowWaitTimeMillisLock) {
-if (waitTime > maxBorrowWaitTimeMillis) {
-maxBorrowWaitTimeMillis = waitTime;
+
+// lock-free optimistic-locking maximum
+long currentMax;
+do {
+currentMax = maxBorrowWaitTimeMillis.get();
+if (currentMax >= waitTime) {
+break;
 }
-}
+} while (!maxBorrowWaitTimeMillis.compareAndSet(currentMax, waitTime));
 }
 
 /**
@@ -1039,12 +1042,21 @@ public abstract class BaseGenericObjectP
 }
 }
 
+/**
+ * Maintains a cache of values for a single metric and reports
+ * statistics on the cached values.
+ */
 private class StatsStore {
 
 private final AtomicLong values[];
 private final int size;
 private int index;
 
+/**
+ * Create a StatsStore with the given cache size.
+ *
+ * @param size number of values to maintain in the cache.
+ */
 public StatsStore(int size) {
 this.size = size;
 values = new AtomicLong[size];
@@ -1053,6 +1065,12 @@ public abstract class BaseGenericObjectP
 }
 }
 
+/**
+ * Adds a value to the cache.  If the cache is full, one of the
+ * existing values is replaced by the new value.
+ *
+ * @param value new value to add to the cache.
+ */
 public synchronized void add(long value) {
 values[index].set(value);
 index++;
@@ -1061,6 +1079,11 @@ public abstract class BaseGenericObjectP
 }
 }
 
+/**
+ * Returns the mean of the cached values.
+ *
+ * @return the mean of the cache, truncated to long
+ */
 public long getMean() {
 double result = 0;
 int counter = 0;
@@ -1073,7 +1096,6 @@ public abstract class BaseGenericObjectP
 }
 }
 return (long) result;
-
 }
 }
 }

Modified: 
tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/DefaultPooledObject.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2/impl/DefaultPooledObject.java?rev=1643814&r1=1643813&r2=1643814&view=diff

svn commit: r1643815 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/tomcat/dbcp/pool2/ java/org/apache/tomcat/dbcp/pool2/impl/ webapps/docs/

[markt]

Author: markt
Date: Mon Dec  8 13:28:01 2014
New Revision: 1643815

URL: http://svn.apache.org/r1643815
Log:
Update fork of Apache Commons Pool2 to latest trunk to pick up fixes including 
one for a potential infinite loop.

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java

tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/DefaultPooledObject.java

tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/LinkedBlockingDeque.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 13:28:01 2014
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766
+/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814

Propchange: tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 13:28:01 2014
@@ -1 +1,2 @@
-/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2:1593516-1627271
+/commons/proper/pool/trunk/src/main/java/org/apache/commons/pool2:1593516-1643813
+/tomcat/trunk/java/org/apache/tomcat/dbcp/pool2:1643814

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java?rev=1643815&r1=1643814&r2=1643815&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
 (original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/tomcat/dbcp/pool2/impl/BaseGenericObjectPool.java
 Mon Dec  8 13:28:01 2014
@@ -111,8 +111,7 @@ public abstract class BaseGenericObjectP
 private final StatsStore activeTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
 private final StatsStore idleTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
 private final StatsStore waitTimes = new 
StatsStore(MEAN_TIMING_STATS_CACHE_SIZE);
-private final Object maxBorrowWaitTimeMillisLock = new Object();
-private volatile long maxBorrowWaitTimeMillis = 0; // 
@GuardedBy("maxBorrowWaitTimeMillisLock")
+private final AtomicLong maxBorrowWaitTimeMillis = new AtomicLong(0L);
 private volatile SwallowedExceptionListener swallowedExceptionListener = 
null;
 
 
@@ -809,7 +808,7 @@ public abstract class BaseGenericObjectP
  * @return maximum wait time in milliseconds since the pool was created
  */
 public final long getMaxBorrowWaitTimeMillis() {
-return maxBorrowWaitTimeMillis;
+return maxBorrowWaitTimeMillis.get();
 }
 
 /**
@@ -873,11 +872,15 @@ public abstract class BaseGenericObjectP
 borrowedCount.incrementAndGet();
 idleTimes.add(p.getIdleTimeMillis());
 waitTimes.add(waitTime);
-synchronized (maxBorrowWaitTimeMillisLock) {
-if (waitTime > maxBorrowWaitTimeMillis) {
-maxBorrowWaitTimeMillis = waitTime;
+
+// lock-free optimistic-locking maximum
+long currentMax;
+do {
+currentMax = maxBorrowWaitTimeMillis.get();
+if (currentMax >= waitTime) {
+break;
 }
-}
+   

[jira] [Updated] (MTOMCAT-290) Parallel deployment - Support version in war file name when using run-war goal

[Olivier Roger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MTOMCAT-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Roger updated MTOMCAT-290:
--
Attachment: tomcat-maven-plugin_parallel-deploy.patch

Simple patch that solve the issue for this exact problem.
Might have side effect ( is there a test suite to run ?)

> Parallel deployment - Support version in war file name when using run-war goal
> --
>
> Key: MTOMCAT-290
> URL: https://issues.apache.org/jira/browse/MTOMCAT-290
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Improvement
>  Components: tomcat7
>Affects Versions: 2.2
> Environment: maven tomcat7
>Reporter: Olivier Roger
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: maven, parallel-deployment, run-war
> Attachments: tomcat-maven-plugin_parallel-deploy.patch
>
>
> When using the tomcat7:run-war goal, the context is created based on the 
> *path* configuration parameter.
> To use parallel deployment 
> (http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) 
> I usually append the timestamp to the path as shown below:
>   org.apache.tomcat.maven
>   tomcat7-maven-plugin
>   
>   /myWar##${maven.build.timestamp}
> This works perfectly when deploying (tomcat7:deploy-only) the war since 
> Tomcat detect the ## and separate the context from the version.
> However there the same process is not applied when running the war 
> (tomocat7:run-war) the *##* characters are URL encoded as *%13%13* and the 
> version (=timestamp) is in the resulting context.
> Usually all character should be URL encoded as it is done as the moment, but 
> this case of parallel deployement might be an exception. (feature was 
> introducted in tomcat7).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] tomcat-maven-plugin pull request: MTOMCAT-290 - Fix for parallel d...

[oroger]

GitHub user oroger opened a pull request:

https://github.com/apache/tomcat-maven-plugin/pull/14

MTOMCAT-290 - Fix for parallel deployment

Fix for the probleme explained in MTOMCAT-290 
(https://issues.apache.org/jira/browse/MTOMCAT-290).
This fix simply strip the version, if present, from the path when running a 
WAR.

BEWARE: I did not look into the internals of the project, this patch might 
have side-effects should not have side effects but I could not verify it (Is 
there a test suite to run for this plugin?)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/oroger/tomcat-maven-plugin trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomcat-maven-plugin/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit dc29fabf542812f84df03581a5f20b747794edf6
Author: Olivier Roger 
Date:   2014-12-08T14:04:45Z

Fix for parallel deployment




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Commented] (MTOMCAT-290) Parallel deployment - Support version in war file name when using run-war goal

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MTOMCAT-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237887#comment-14237887
 ] 

ASF GitHub Bot commented on MTOMCAT-290:


GitHub user oroger opened a pull request:

https://github.com/apache/tomcat-maven-plugin/pull/14

MTOMCAT-290 - Fix for parallel deployment

Fix for the probleme explained in MTOMCAT-290 
(https://issues.apache.org/jira/browse/MTOMCAT-290).
This fix simply strip the version, if present, from the path when running a 
WAR.

BEWARE: I did not look into the internals of the project, this patch might 
have side-effects should not have side effects but I could not verify it (Is 
there a test suite to run for this plugin?)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/oroger/tomcat-maven-plugin trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomcat-maven-plugin/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit dc29fabf542812f84df03581a5f20b747794edf6
Author: Olivier Roger 
Date:   2014-12-08T14:04:45Z

Fix for parallel deployment




> Parallel deployment - Support version in war file name when using run-war goal
> --
>
> Key: MTOMCAT-290
> URL: https://issues.apache.org/jira/browse/MTOMCAT-290
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Improvement
>  Components: tomcat7
>Affects Versions: 2.2
> Environment: maven tomcat7
>Reporter: Olivier Roger
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
>  Labels: maven, parallel-deployment, run-war
> Attachments: tomcat-maven-plugin_parallel-deploy.patch
>
>
> When using the tomcat7:run-war goal, the context is created based on the 
> *path* configuration parameter.
> To use parallel deployment 
> (http://jagadesh4java.blogspot.be/2013/08/tomcat-7-parallel-deployment.html) 
> I usually append the timestamp to the path as shown below:
>   org.apache.tomcat.maven
>   tomcat7-maven-plugin
>   
>   /myWar##${maven.build.timestamp}
> This works perfectly when deploying (tomcat7:deploy-only) the war since 
> Tomcat detect the ## and separate the context from the version.
> However there the same process is not applied when running the war 
> (tomocat7:run-war) the *##* characters are URL encoded as *%13%13* and the 
> version (=timestamp) is in the resulting context.
> Usually all character should be URL encoded as it is done as the moment, but 
> this case of parallel deployement might be an exception. (feature was 
> introducted in tomcat7).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] tomcat-maven-plugin pull request: Bind Tomcat to an address via co...

[seanking]

GitHub user seanking opened a pull request:

https://github.com/apache/tomcat-maven-plugin/pull/15

Bind Tomcat to an address via command-line option

Introduce a -httpAddress command-line option to the Tomcat Runner.
Update the Runner to bind Tomcat to the specified address.

Ex: java -jar webapp.war -httpAddress somehostname

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/seanking/tomcat-maven-plugin 
bind-to-http-address

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomcat-maven-plugin/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit 30a63584c3124ad576e65823bd06aa932c594ee4
Author: Sean King 
Date:   2014-12-08T19:22:53Z

Bind Tomcat to an address via command-line option

Introduce a -httpAddress command-line option to the Tomcat Runner.
Update the Runner to bind Tomcat to the specified address.

Ex: java -jar webapp.war -httpAddress somehostname




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1642773 - in /tomcat/trunk/java/org/apache/tomcat/websocket: WsFrameBase.java WsRemoteEndpointImplBase.java

[Mark Thomas]

On 04/12/2014 14:04, Rémy Maucherat wrote:
> 2014-12-04 14:58 GMT+01:00 Mark Thomas :
> 
>> Shouldn't there still be a single empty message in that case? Otherwise,
>> how is the client meant to differentiate between no write and a write of
>> zero length?
>>
> The problem I am trying to fix is extra empty messages when the writer is
> not actually used (due to an error), so I might as well not do anything.

I understand what you are trying to do but I'm still trying to
understand the circumstances that lead this situation. Can you provide
some more detail on what triggers the error?

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643906 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java

[markt]

Author: markt
Date: Mon Dec  8 20:31:23 2014
New Revision: 1643906

URL: http://svn.apache.org/r1643906
Log:
Add a comment to explain what is going on and why

Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java

Modified: 
tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java?rev=1643906&r1=1643905&r2=1643906&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java 
Mon Dec  8 20:31:23 2014
@@ -937,6 +937,8 @@ public abstract class WsRemoteEndpointIm
 sm.getString("wsRemoteEndpoint.closedOutputStream"));
 }
 
+// Optimisation. If there is no data to flush then do not send an
+// empty message.
 if (buffer.position() > 0) {
 doWrite(false);
 }



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643908 - /tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java

[markt]

Author: markt
Date: Mon Dec  8 20:38:48 2014
New Revision: 1643908

URL: http://svn.apache.org/r1643908
Log:
Rename method since equals() has a specific meaning that doesn't seem the right 
fit for this use case. This also stops the IDE complaining that hashCode() 
needs to be overridden because equals has been.

Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java

Modified: 
tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java?rev=1643908&r1=1643907&r2=1643908&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java 
Mon Dec  8 20:38:48 2014
@@ -132,7 +132,7 @@ public class PojoMethodMapping {
 MessageHandlerInfo messageHandler = new 
MessageHandlerInfo(method, decoders);
 boolean found = false;
 for (MessageHandlerInfo otherMessageHandler : onMessage) {
-if (messageHandler.equals(otherMessageHandler)) {
+if 
(messageHandler.targetsSameWebSocketMessageType(otherMessageHandler)) {
 found = true;
 if (currentClazz == clazzPojo ||
 (currentClazz != clazzPojo
@@ -589,12 +589,10 @@ public class PojoMethodMapping {
 }
 
 
-@Override
-public boolean equals(Object obj) {
-if (obj == null || !(obj instanceof MessageHandlerInfo)) {
+public boolean targetsSameWebSocketMessageType(MessageHandlerInfo 
otherHandler) {
+if (otherHandler == null) {
 return false;
 }
-MessageHandlerInfo otherHandler = (MessageHandlerInfo) obj;
 if (indexByteArray >= 0 && otherHandler.indexByteArray >= 0) {
 return true;
 }



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643008 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Util.java pojo/PojoMethodMapping.java

[Mark Thomas]

On 05/12/2014 18:42, Mark Thomas wrote:
> On 04/12/2014 14:21, Rémy Maucherat wrote:
>> 2014-12-04 15:01 GMT+01:00 Mark Thomas :
>>
 Ah actually, it is a mix then of the two, it should implement what is
 marked as WSC-4.8.1 in the spec instead.
>>>
>>> I thought that was what was implemented (prior to r1643008). What did I
>>> get wrong?
>>>
>> The test is fairly explicit that the annotated methods from superclasses
>> should be used. And that's what the spec is really saying actually, but
>> it's nearly impossible to understand IMO.
> 
> Ah. Now I get it.
> 
>> It mostly defines some exceptions
>> to that inheritance:
>> - if the subclass does not have its @*Endpoint annotation (fine) [spec
>> quote: For example, a Java class
>> that inherits from a Java class annotated with class level WebSocket
>> annotations does not itself become an
>> annotated endpoint, unless it itself is annotated with a class level
>> WebSocket annotation.]
>> - if an annotated method is overridden by a non annotated method (harder)
>>
>> It starts with a confusing statement [The websocket annotation behaviors
>> defined by this specification are not passed down the Java class
>> inheritance hierarchy. They apply only to the Java class on which they are
>> marked.]. So the method level annotations would still be there in the
>> superclass and used unless the subclass overrides them.
> 
> This is the point I missed in my original meaning. I agree with your
> interpretation.
> 
>> So I tried to do that now, but my commit (r1643065) is lost somewhere.
> 
> That should have come through by now so I'll go and have a look.

Found it. Looks good. I made one minor tweak but no functional change.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643912 - in /tomcat/trunk: build.properties.default build.xml res/patches/ res/patches/commons-logging-log4j2.patch

[rjung]

Author: rjung
Date: Mon Dec  8 20:51:01 2014
New Revision: 1643912

URL: http://svn.apache.org/r1643912
Log:
Add support for Log4J2 to juli.

Log4J2 has builtin support for commons logging.
But using that would mean the Log4J2 jar files have
to be put on the CLASSPATH. One can instead integrate
Log4J2 similar to Log4J and the code is very similar
to what is in org.apache.logging.log4j.jcl.

Needs documentation.

Probably a candidate for upstream (commons logging).

Added:
tomcat/trunk/res/patches/
tomcat/trunk/res/patches/commons-logging-log4j2.patch   (with props)
Modified:
tomcat/trunk/build.properties.default
tomcat/trunk/build.xml

Modified: tomcat/trunk/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1643912&r1=1643911&r2=1643912&view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Mon Dec  8 20:51:01 2014
@@ -92,7 +92,7 @@ base-maven.loc=http://repo.maven.apache.
 # - log4j
 # - logkit
 # - servletapi
-commons-logging.version=1.1.3
+commons-logging.version=1.2
 commons-logging.home=${base.path}/commons-logging-${commons-logging.version}
 
commons-logging-src.loc.1=${base-commons.loc.1}/logging/source/commons-logging-${commons-logging.version}-src.tar.gz
 
commons-logging-src.loc.2=${base-commons.loc.2}/logging/source/commons-logging-${commons-logging.version}-src.tar.gz
@@ -104,6 +104,14 @@ avalon-framework.home=${base.path}/avalo
 
avalon-framework.loc=${base-maven.loc}/avalon-framework/avalon-framework/${avalon-framework.version}/avalon-framework-${avalon-framework.version}.jar
 
avalon-framework.jar=${avalon-framework.home}/avalon-framework-${avalon-framework.version}.jar
 
+# - log4j2 (required by our extension of commons logging) -
+log4j2.version=2.1
+log4j2.home=${base.path}/log4j2-${log4j2.version}
+log4j2-api.loc=${base-maven.loc}/org/apache/logging/log4j/log4j-api/${log4j2.version}/log4j-api-${log4j2.version}.jar
+log4j2-core.loc=${base-maven.loc}/org/apache/logging/log4j/log4j-core/${log4j2.version}/log4j-core-${log4j2.version}.jar
+log4j2-api.jar=${log4j2.home}/log4j-api-${log4j2.version}.jar
+log4j2-core.jar=${log4j2.home}/log4j-core-${log4j2.version}.jar
+
 # - log4j (required by commons logging) -
 log4j.version=1.2.17
 log4j.home=${base.path}/log4j-${log4j.version}

Modified: tomcat/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1643912&r1=1643911&r2=1643912&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Mon Dec  8 20:51:01 2014
@@ -1529,6 +1529,18 @@
 
 
 
+  
+  
+  
+
+
+
+  
+  
+  
+
+
+
   
   
   
@@ -1577,8 +1589,15 @@
 
 
+
+
 
   
+  
+  
   
   
   

Added: tomcat/trunk/res/patches/commons-logging-log4j2.patch
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/res/patches/commons-logging-log4j2.patch?rev=1643912&view=auto
==
--- tomcat/trunk/res/patches/commons-logging-log4j2.patch (added)
+++ tomcat/trunk/res/patches/commons-logging-log4j2.patch Mon Dec  8 20:51:01 
2014
@@ -0,0 +1,358 @@
+Index: build2.xml
+===
+--- build2.xml 2014-12-08 09:08:58.752474000 +0100
 build2.xml 2014-12-06 23:21:57.919049000 +0100
+@@ -76,6 +76,7 @@
+   
+   
+   
++  
+   
+   
+   
+@@ -191,10 +192,19 @@
+ 
+   
+ 
++  
++  
++
++
++
++
++  
++
+   
+   
+ 
+ 
++
+   
+ 
+   
+@@ -207,6 +217,7 @@
+   
+   
+   
++  
+   
+   
+   
+@@ -230,6 +241,7 @@
+ 
+ 
+ 
++
+ 
+   
+ 
+@@ -248,6 +260,7 @@
+ Log4j12: ${log4j12.jar}
+ 
+ 
++Log4j2: ${log4j2.jar}
+ LogKit: ${logkit.jar}
+ Avalon-Framework: ${avalon-framework.jar}
+ 
+@@ -285,6 +298,7 @@
+ 
+ 
+ 
++
+ 
+   
+ 
+@@ -308,6 +322,13 @@
+ -->
+   
+   
++  
++
++*** WARNING ***
++Log4j 2 not found: Cannot Build Log4jLog
++
++  
++  
+   
+ 
+ *** WARNING ***
+@@ -336,17 +357,25 @@
+ 
+   
+ 
++  
++
++*** WARNING ***
++Log4J 2.x Jar not found: Cannot execute 2.x tests
++
++  
++
+   
++
depends='log4j12-warning,log4j13-warning,log4j2-warning,logkit-warning,jdk1.4-warning,avalon-framework-warning,compile-1.4'/>
+ 
+   
++
depends="prepare,discovery,warning,show-lib-presence,compile-non-log4j,compile-log4j12,compile-log4j2,compile-log4j13,build-jar"/>
+ 
+   
+ 
+ 
+ 
+ 
++
+ 
+ 
+   
+@@ -364,6 +393,7 @@
+   
+ 
+   
++  
+ 
+   
+@@ -457,6 +487,30 @@
+ 
+   
+ 
++  
++
++
++
++  
++  
++
++ 
++  
++
++  
++
++  

Re: svn commit: r1642773 - in /tomcat/trunk/java/org/apache/tomcat/websocket: WsFrameBase.java WsRemoteEndpointImplBase.java

[Rémy Maucherat]

2014-12-08 21:18 GMT+01:00 Mark Thomas :

> On 04/12/2014 14:04, Rémy Maucherat wrote:
> > 2014-12-04 14:58 GMT+01:00 Mark Thomas :
> >
> >> Shouldn't there still be a single empty message in that case? Otherwise,
> >> how is the client meant to differentiate between no write and a write of
> >> zero length?
> >>
> > The problem I am trying to fix is extra empty messages when the writer is
> > not actually used (due to an error), so I might as well not do anything.
>
> I understand what you are trying to do but I'm still trying to
> understand the circumstances that lead this situation. Can you provide
> some more detail on what triggers the error?
>
> A test expects some data in a message following an exception, and instead
gets an empty message first due to some writer mechanics (sent because the
writer is closed). The spec doesn't say anything about these empty
messages, so there is no reason to send them, it is not actually an
optimization.

Rémy

Re: svn commit: r1643194 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Constants.java LocalStrings.properties TransformationFactory.java Util.java WsWebSocketContainer.java

[Mark Thomas]

On 05/12/2014 19:11, Rémy Maucherat wrote:
> 2014-12-05 19:52 GMT+01:00 Mark Thomas :
> 
>> On 05/12/2014 08:42, r...@apache.org wrote:



>>> +// Configuration for extensions
>>> +static final boolean DISABLE_BUILTIN_EXTENSIONS =
>>> +
>> Boolean.getBoolean("org.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS");
>>> +static final boolean ALLOW_UNSUPPORTED_EXTENSIONS =
>>> +
>> Boolean.getBoolean("org.apache.tomcat.websocket.ALLOW_UNSUPPORTED_EXTENSIONS");
>>> +
>>
>> I'm against adding both of the above solely to work around broken TCK
>> tests. Do they have any real world use case?
>>
> 
> They're trying to test the existing APIs, the user indeed has a (rather
> well hidden) way to set its own extensions. So this is rather legitimate.

Yes, but without the ability to add an implementation of that extension
there is no point to the user setting their own extensions.

> But then you would like to throw an error. Fine with me, but things go both
> ways: unless there's something in the spec which says the server should
> throw an error if it doesn't know an extension, then it should be
> acceptable to at least have an option for that behavior.

I still think that throwing an Deployment error is the only sensible
behaviour if an application tries to set its own extension.

I do take the point about the API being there. If it can not be used for
anything, what is the point of even having it.

The more I think about this, the more I think it made no sense to
include extensions on the server side without an API to add extension
implementations. But that boat has sailed.

I appreciate that these options are necessary in order to pass the TCK
and I don't want to get in the way of that. How about the following:

- keep the two options as above
- mark them as deprecated with some text to the effect that they are
only present to enable the TCK to pass for the WebSocket 1.1 API and
they are expected to be removed once the WebSocket API includes a
mechanism for adding custom extension implementations.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1642773 - in /tomcat/trunk/java/org/apache/tomcat/websocket: WsFrameBase.java WsRemoteEndpointImplBase.java

[Mark Thomas]

On 08/12/2014 20:54, Rémy Maucherat wrote:
> 2014-12-08 21:18 GMT+01:00 Mark Thomas :
> 
>> On 04/12/2014 14:04, Rémy Maucherat wrote:
>>> 2014-12-04 14:58 GMT+01:00 Mark Thomas :
>>>
 Shouldn't there still be a single empty message in that case? Otherwise,
 how is the client meant to differentiate between no write and a write of
 zero length?

>>> The problem I am trying to fix is extra empty messages when the writer is
>>> not actually used (due to an error), so I might as well not do anything.
>>
>> I understand what you are trying to do but I'm still trying to
>> understand the circumstances that lead this situation. Can you provide
>> some more detail on what triggers the error?
>>
> A test expects some data in a message following an exception, and instead
> gets an empty message first due to some writer mechanics (sent because the
> writer is closed). The spec doesn't say anything about these empty
> messages, so there is no reason to send them, it is not actually an
> optimization.

What triggers the exception. That is the bit I don't understand.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643912 - in /tomcat/trunk: build.properties.default build.xml res/patches/ res/patches/commons-logging-log4j2.patch

[Konstantin Kolinko]

2014-12-08 23:51 GMT+03:00  :
> Author: rjung
> Date: Mon Dec  8 20:51:01 2014
> New Revision: 1643912
>
> URL: http://svn.apache.org/r1643912
> Log:
> Add support for Log4J2 to juli.
>
> Log4J2 has builtin support for commons logging.
> But using that would mean the Log4J2 jar files have
> to be put on the CLASSPATH. One can instead integrate
> Log4J2 similar to Log4J and the code is very similar
> to what is in org.apache.logging.log4j.jcl.
>
> Needs documentation.

1. Log4J2 can also be plugged into JUL. (I think that would be the
easiest approach, using already existing library).

http://logging.apache.org/log4j/2.x/log4j-jul/index.html

2. I thought that the way to leverage commons logging for Log4j is to
take their jcl bridge (3 classes)
http://logging.apache.org/log4j/2.x/log4j-jcl/index.html

and

1) apply package renaming to those 3 classes
2) compile those 3 classes against our package-renamed
extra/tomcat-juli[-adapters].jar  and package into separate JAR with a
separate ant target.

It shall be close to what you are doing, but it looks that you are
patching commons-logging build file.

3. Generally, I do not like  as a long-term solution, as that
tool is not available under Windows, unless you specifically configure
it (needs update to BUILDING.txt)/

4. When I downloaded commons-logging 1.2 from commons site, I noted
that there is a difference in packaging.

Version 1.1.3 had two jars (.jar and adapters.jar),  where 1.2 only
one jar (with all classes from the adapters file).  I have not
investigated whether that was an intended change.

You changed version to 1.2. Does the build still produce the
-adapters.jar file.  If it does not then installation instruction
(logging-howto) and build file that uploads jars to Maven need to be
updated.

Best regards,
Konstantin Kolinko

> Probably a candidate for upstream (commons logging).

Interesting.

> Added:
> tomcat/trunk/res/patches/
> tomcat/trunk/res/patches/commons-logging-log4j2.patch   (with props)
> Modified:
> tomcat/trunk/build.properties.default
> tomcat/trunk/build.xml
>
> Modified: tomcat/trunk/build.properties.default
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1643912&r1=1643911&r2=1643912&view=diff
> ==
> --- tomcat/trunk/build.properties.default (original)
> +++ tomcat/trunk/build.properties.default Mon Dec  8 20:51:01 2014
> @@ -92,7 +92,7 @@ base-maven.loc=http://repo.maven.apache.
>  # - log4j
>  # - logkit
>  # - servletapi
> -commons-logging.version=1.1.3
> +commons-logging.version=1.2
> ...

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 57331] New: Allow ExpiresFilter to use "year" as synonym for "years" in its configuration

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=57331

Bug ID: 57331
   Summary: Allow ExpiresFilter to use "year" as synonym for
"years" in its configuration
   Product: Tomcat 7
   Version: 7.0.57
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: knst.koli...@gmail.com

The current code is

if ("years".equalsIgnoreCase(currentToken)) {
durationUnit = DurationUnit.YEAR;
} else if ("month".equalsIgnoreCase(currentToken) ||
"months".equalsIgnoreCase(currentToken)) {
durationUnit = DurationUnit.MONTH;
...

The above if/else tree misses "year" case. All other time units have support
for singular form, e.g. "months"/"month" above.

This was observed by a stackoverflow user [1]. 
The following configuration fails:

  
   ExpiresDefault
   access plus 1 year
 

but succeeds if one replaces s/year/years/.


[1]
http://stackoverflow.com/questions/27353512/how-to-configure-expires-filter-in-tomcat-7

-- 
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: r1643937 - /tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

[violetagg]

Author: violetagg
Date: Mon Dec  8 21:40:06 2014
New Revision: 1643937

URL: http://svn.apache.org/r1643937
Log:
Additional method was introduced to StandardRoot in order to be able to extend 
classResources.

Modified:
tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

Modified: tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643937&r1=1643936&r2=1643937&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java Mon 
Dec  8 21:40:06 2014
@@ -461,6 +461,11 @@ public class StandardRoot extends Lifecy
 return classResources.toArray(new WebResourceSet[0]);
 }
 
+protected void addClassResources(WebResourceSet webResourceSet) {
+webResourceSet.setRoot(this);
+classResources.add(webResourceSet);
+}
+
 @Override
 public void setAllowLinking(boolean allowLinking) {
 this.allowLinking = allowLinking;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643938 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/webresources/StandardRoot.java

[violetagg]

Author: violetagg
Date: Mon Dec  8 21:42:12 2014
New Revision: 1643938

URL: http://svn.apache.org/r1643938
Log:
Merged revision 1643937 from tomcat/trunk:
Additional method was introduced to StandardRoot in order to be able to extend 
classResources.

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Dec  8 21:42:12 2014
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814
+/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,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,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1643002,1643045,1643054-1643055,1643066,1643121,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643938&r1=1643937&r2=1643938&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
Mon Dec  8 21:42:12 2014
@@ -461,6 +461,11 @@ public class StandardRoot extends Lifecy
 return classResources.toArray(new WebResourceSet[0]);
 }
 
+protected void addClassResources(WebResourceSet webResourceSet) {
+webResourceSet.setRoot(this);
+classResources.add(webResourceSet);
+}
+
 @Override
 public void setAllowLinking(boolean allowLinking) {
 this.allowLinking = allowLinking;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643912 - in /tomcat/trunk: build.properties.default build.xml res/patches/ res/patches/commons-logging-log4j2.patch

[Rainer Jung]

Hi Konstantin,

Am 08.12.2014 um 22:10 schrieb Konstantin Kolinko:

2014-12-08 23:51 GMT+03:00  :

Author: rjung
Date: Mon Dec  8 20:51:01 2014
New Revision: 1643912

URL: http://svn.apache.org/r1643912
Log:
Add support for Log4J2 to juli.

Log4J2 has builtin support for commons logging.
But using that would mean the Log4J2 jar files have
to be put on the CLASSPATH. One can instead integrate
Log4J2 similar to Log4J and the code is very similar
to what is in org.apache.logging.log4j.jcl.

Needs documentation.


1. Log4J2 can also be plugged into JUL. (I think that would be the
easiest approach, using already existing library).

http://logging.apache.org/log4j/2.x/log4j-jul/index.html


But that means you have to add 3 log4j2 jar files to the CLASSPATH. 
Since we usually tell people to be restrictive with adding jars to the 
CLASSPATH, I found it nicer to do it in a way analogous with our log4j 
integration.



2. I thought that the way to leverage commons logging for Log4j is to
take their jcl bridge (3 classes)
http://logging.apache.org/log4j/2.x/log4j-jcl/index.html

and

1) apply package renaming to those 3 classes
2) compile those 3 classes against our package-renamed
extra/tomcat-juli[-adapters].jar  and package into separate JAR with a
separate ant target.

It shall be close to what you are doing, but it looks that you are
patching commons-logging build file.


Tried that, but I didn't find it satisfying:

The jcl package contains a Factory class that is meant to replace the 
factory class that is available in jcl. It will be found by a services 
entry. Now that factory is not as flexible as the default one: the 
default one will find jcl implementations per classloader. Example when 
log4j is in place: Since the implementations are in the juli-adapters 
jar, the first created logger - before the common loader is active - 
will be a JDK4 logger, then after the common loader was started, it will 
find juli-adapters and use a log4j logger, the same for the tomcat 
loggers initialized for the webapps.


When using the log4j2 jcl bridge, again the three jar files (api, core 
and jcl) of log4j2 must be in the CLASSPATH. Otherwise the factory fails.


That's why I extended the existing IMHO more clever factory to log4j2 
and provide a jcl Log impl based on log4j2 (similar to Log4JLogger). 
This impl can now be copied with only small adjustments from log4j2 
jcl/Log4jLog.



3. Generally, I do not like  as a long-term solution, as that
tool is not available under Windows, unless you specifically configure
it (needs update to BUILDING.txt)/


Any better idea? I can try to get the stuff in upstream jcl, but I think 
it's not very likely they'll do a release.


Should I instead check in the resulting build2.xml and the 2 classes 
into a res sub directory and copy the files out from there? The files 
would hevae to be updated if we move to a newer jcl version, which might 
well happen never. I could keep the patch file for reference and to make 
merging after upgrading jcl easier.



4. When I downloaded commons-logging 1.2 from commons site, I noted
that there is a difference in packaging.

Version 1.1.3 had two jars (.jar and adapters.jar),  where 1.2 only
one jar (with all classes from the adapters file).  I have not
investigated whether that was an intended change.



You changed version to 1.2. Does the build still produce the
-adapters.jar file.  If it does not then installation instruction
(logging-howto) and build file that uploads jars to Maven need to be
updated.


It does produce commons-logging-1.2.jar, commons-logging-api-1.2.jar and 
commons-logging-adapters-1.2.jar. But: our two juli artefacts are not 
created using the build(2).xml from jcl. Instead we already have 
separate jar tasks in our own build.xml, because our two juli jar files 
do not fit any of the existing build artefacts of jcl, even before the 
switch to 1.2. So that part does not change.


I will care about docs as soon as the log4j2 integration stabilizes. It 
is what I came up with after experimenting with the out-of-the-box 
integration of log4j2 into jul and jcl. I didn't like the need to put 
all the jars on the CLASSPATH, thus tried to provide an integration with 
the same formal properties as our log4j integration. Do your share that 
goal, or do you think adding all log4j2 jars on the CLASSPATH is OK? Of 
course that yould be much easier from an integration point of view. I'm 
simply not sure about negative consequences.



Best regards,


Thanks a bunch for your review.

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643912 - in /tomcat/trunk: build.properties.default build.xml res/patches/ res/patches/commons-logging-log4j2.patch

[Rainer Jung]

Am 08.12.2014 um 22:58 schrieb Rainer Jung:

Hi Konstantin,

Am 08.12.2014 um 22:10 schrieb Konstantin Kolinko:

2014-12-08 23:51 GMT+03:00  :

Author: rjung
Date: Mon Dec  8 20:51:01 2014
New Revision: 1643912

URL: http://svn.apache.org/r1643912
Log:
Add support for Log4J2 to juli.

Log4J2 has builtin support for commons logging.
But using that would mean the Log4J2 jar files have
to be put on the CLASSPATH. One can instead integrate
Log4J2 similar to Log4J and the code is very similar
to what is in org.apache.logging.log4j.jcl.

Needs documentation.


1. Log4J2 can also be plugged into JUL. (I think that would be the
easiest approach, using already existing library).

http://logging.apache.org/log4j/2.x/log4j-jul/index.html


But that means you have to add 3 log4j2 jar files to the CLASSPATH.
Since we usually tell people to be restrictive with adding jars to the
CLASSPATH, I found it nicer to do it in a way analogous with our log4j
integration.


2. I thought that the way to leverage commons logging for Log4j is to
take their jcl bridge (3 classes)
http://logging.apache.org/log4j/2.x/log4j-jcl/index.html

and

1) apply package renaming to those 3 classes
2) compile those 3 classes against our package-renamed
extra/tomcat-juli[-adapters].jar  and package into separate JAR with a
separate ant target.

It shall be close to what you are doing, but it looks that you are
patching commons-logging build file.


Tried that, but I didn't find it satisfying:

The jcl package contains a Factory class that is meant to replace the
factory class that is available in jcl. It will be found by a services
entry. Now that factory is not as flexible as the default one: the
default one will find jcl implementations per classloader. Example when
log4j is in place: Since the implementations are in the juli-adapters
jar, the first created logger - before the common loader is active -
will be a JDK4 logger, then after the common loader was started, it will
find juli-adapters and use a log4j logger, the same for the tomcat
loggers initialized for the webapps.

When using the log4j2 jcl bridge, again the three jar files (api, core
and jcl) of log4j2 must be in the CLASSPATH. Otherwise the factory fails.

That's why I extended the existing IMHO more clever factory to log4j2
and provide a jcl Log impl based on log4j2 (similar to Log4JLogger).
This impl can now be copied with only small adjustments from log4j2
jcl/Log4jLog.


3. Generally, I do not like  as a long-term solution, as that
tool is not available under Windows, unless you specifically configure
it (needs update to BUILDING.txt)/


Any better idea? I can try to get the stuff in upstream jcl, but I think
it's not very likely they'll do a release.

Should I instead check in the resulting build2.xml and the 2 classes
into a res sub directory and copy the files out from there? The files
would hevae to be updated if we move to a newer jcl version, which might
well happen never. I could keep the patch file for reference and to make
merging after upgrading jcl easier.


4. When I downloaded commons-logging 1.2 from commons site, I noted
that there is a difference in packaging.

Version 1.1.3 had two jars (.jar and adapters.jar),  where 1.2 only
one jar (with all classes from the adapters file).  I have not
investigated whether that was an intended change.



You changed version to 1.2. Does the build still produce the
-adapters.jar file.  If it does not then installation instruction
(logging-howto) and build file that uploads jars to Maven need to be
updated.


It does produce commons-logging-1.2.jar, commons-logging-api-1.2.jar and
commons-logging-adapters-1.2.jar. But: our two juli artefacts are not
created using the build(2).xml from jcl. Instead we already have
separate jar tasks in our own build.xml, because our two juli jar files
do not fit any of the existing build artefacts of jcl, even before the
switch to 1.2. So that part does not change.

I will care about docs as soon as the log4j2 integration stabilizes. It
is what I came up with after experimenting with the out-of-the-box
integration of log4j2 into jul and jcl. I didn't like the need to put
all the jars on the CLASSPATH, thus tried to provide an integration with
the same formal properties as our log4j integration. Do your share that
goal, or do you think adding all log4j2 jars on the CLASSPATH is OK? Of
course that yould be much easier from an integration point of view. I'm
simply not sure about negative consequences.


Adding to self: not only does the out-of-the-box integration need the 
various log4j2 jar files on the CLASSPATH, but if you want to configure 
it using the config file search as a resource via classloader, then 
again it must be found by the system class loader. But since the webapp 
loaders delegate first to the system class loaders, the jar files and 
the config file will IMHO impact the wanted isolation of the webapps.


Using the "traditional" juli-adapters plus original factory approach, 
let

Re: svn commit: r1642773 - in /tomcat/trunk/java/org/apache/tomcat/websocket: WsFrameBase.java WsRemoteEndpointImplBase.java

[Rémy Maucherat]

2014-12-08 21:59 GMT+01:00 Mark Thomas :

> What triggers the exception. That is the bit I don't understand.
>
> The test is throwing an exception, it goes to onError which writes a
message, but the writer empty message gets sent first. From what I remember.

To go further in this discussion, please provide information on where the
specification states empty messages are sent when using a writer or output
stream.

Rémy

Re: svn commit: r1643194 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Constants.java LocalStrings.properties TransformationFactory.java Util.java WsWebSocketContainer.java

[Rémy Maucherat]

2014-12-08 21:56 GMT+01:00 Mark Thomas :

> The more I think about this, the more I think it made no sense to
> include extensions on the server side without an API to add extension
> implementations. But that boat has sailed.
>

Ok, but these APIs are there for the time being, as I said these folks just
wish to test them.

>
> I appreciate that these options are necessary in order to pass the TCK
> and I don't want to get in the way of that. How about the following:
>
> - keep the two options as above
> - mark them as deprecated with some text to the effect that they are
> only present to enable the TCK to pass for the WebSocket 1.1 API and
> they are expected to be removed once the WebSocket API includes a
> mechanism for adding custom extension implementations.
>
> Unless the EG works on this item, this seems an established behavior
rather than some deprecated thing. I'll be very happy to remove them when
things change.

Rémy

Re: svn commit: r1643766 - /tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

[Mark Thomas]

On 08/12/2014 09:04, violet...@apache.org wrote:
> Author: violetagg
> Date: Mon Dec  8 09:04:56 2014
> New Revision: 1643766
> 
> URL: http://svn.apache.org/r1643766
> Log:
> Extract several "protected" methods in order to make StandardRoot easier for 
> extending.
> 
> Modified:
> tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
> 
> Modified: tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643766&r1=1643765&r2=1643766&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java Mon 
> Dec  8 09:04:56 2014
> @@ -457,6 +457,10 @@ public class StandardRoot extends Lifecy
>  return postResources.toArray(new WebResourceSet[0]);
>  }
>  
> +protected WebResourceSet[] getClassResources() {
> +return classResources.toArray(new WebResourceSet[0]);
> +}
> +
>  @Override
>  public void setAllowLinking(boolean allowLinking) {
>  this.allowLinking = allowLinking;

What is the use case for this one? classResources was intended to be
internal to StandardRoot.

> @@ -633,9 +637,7 @@ public class StandardRoot extends Lifecy
>  
>  cacheJmxName = register(cache, getObjectNameKeyProperties() + 
> ",name=Cache");
>  
> -// Ensure support for jar:war:file:/ URLs will be available (required
> -// for resource JARs in packed WAR files).
> -TomcatURLStreamHandlerFactory.register();
> +registerURLStreamHandlerFactory();
>  
>  if (context == null) {
>  throw new IllegalStateException(
> @@ -649,29 +651,17 @@ public class StandardRoot extends Lifecy
>  }
>  }
>  
> +protected void registerURLStreamHandlerFactory() {
> +// Ensure support for jar:war:file:/ URLs will be available (required
> +// for resource JARs in packed WAR files).
> +TomcatURLStreamHandlerFactory.register();
> +}
> +

I can see the use case for these two. +1.


>  @Override
>  protected void startInternal() throws LifecycleException {
> -String docBase = context.getDocBase();
> -
>  mainResources.clear();
>  
> -if (docBase == null) {
> -main = new EmptyResourceSet(this);
> -} else {
> -File f = new File(docBase);
> -if (!f.isAbsolute()) {
> -f = new File(((Host)context.getParent()).getAppBaseFile(), 
> f.getPath());
> -}
> -if (f.isDirectory()) {
> -main = new DirResourceSet(this, "/", f.getAbsolutePath(), 
> "/");
> -} else if(f.isFile() && docBase.endsWith(".war")) {
> -main = new JarResourceSet(this, "/", f.getAbsolutePath(), 
> "/");
> -} else {
> -throw new IllegalArgumentException(
> -sm.getString("standardRoot.startInvalidMain",
> -f.getAbsolutePath()));
> -}
> -}
> +main = createMainResourceSet();
>  
>  mainResources.add(main);
>  
> @@ -694,6 +684,31 @@ public class StandardRoot extends Lifecy
>  setState(LifecycleState.STARTING);
>  }
>  
> +protected WebResourceSet createMainResourceSet() {
> +String docBase = context.getDocBase();
> +
> +WebResourceSet mainResourceSet;
> +if (docBase == null) {
> +mainResourceSet = new EmptyResourceSet(this);
> +} else {
> +File f = new File(docBase);
> +if (!f.isAbsolute()) {
> +f = new File(((Host)context.getParent()).getAppBaseFile(), 
> f.getPath());
> +}
> +if (f.isDirectory()) {
> +mainResourceSet = new DirResourceSet(this, "/", 
> f.getAbsolutePath(), "/");
> +} else if(f.isFile() && docBase.endsWith(".war")) {
> +mainResourceSet = new JarResourceSet(this, "/", 
> f.getAbsolutePath(), "/");
> +} else {
> +throw new IllegalArgumentException(
> +sm.getString("standardRoot.startInvalidMain",
> +f.getAbsolutePath()));
> +}
> +}
> +
> +return mainResourceSet;
> +}
> +

I'm curious about the use case for this too.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643912 - in /tomcat/trunk: build.properties.default build.xml res/patches/ res/patches/commons-logging-log4j2.patch

[Konstantin Kolinko]

2014-12-09 1:24 GMT+03:00 Rainer Jung :
>
>> 
>
> Adding to self: not only does the out-of-the-box integration need the
> various log4j2 jar files on the CLASSPATH, but if you want to configure it
> using the config file search as a resource via classloader, then again it
> must be found by the system class loader. But since the webapp loaders
> delegate first to the system class loaders, the jar files and the config
> file will IMHO impact the wanted isolation of the webapps.
>
> Using the "traditional" juli-adapters plus original factory approach, lets
> us keep the jar files and config file in the common loader. The common
> loader by default is not queried early by the webapp loader, but instead
> only as a fallback.

1.  If I understand correctly, currently there is no such difference
between the system class loader and common class loader. The web
application overrides any of them,  so there is no difference.

I mean this change (7.0.51), in case if you missed it,

  
55943: Improve the implementation of the class loader check
that prevents web applications from trying to override J2SE
implementation classes. As part of this fix, refactor the way a null
parent class loader is handled which enables a number of null checks and
object creation calls to be removed. Note that this change means that,
by default, the web application class loader is now a higher priority
for loading classes than the system class loader.  (markt)
  

Also,
http://tomcat.apache.org/migration-7.html#Tomcat_7.0.x_noteable_changes


2. Regardless of your solution, you cannot perfectly hide Log4j or
Log4j2 from a web application.

For example, if a web application uses commons-logging, it will
autodetect Log4j and switch to it. It may ruin logging configuration
of this web application as it will ignore
WEB-INF/classes/logging.properties and will start looking for Log4J
configuration file.

Being able to overwrite the library at web application level is a good
point (thank you for reminding it),
but personally I do not like such ambiguities in configurations and I
am ready to expect nasty surprises. I cannot say whether it works for
Log4j[N]  without actual testing.


3. If Log4j[N] is used to configure Tomcat logging, I think that it
means that the site administrator is a fan of Log4j and would like all
applications as well to be consistently logging to log4j[N].  It this
case it is up to him to prepare configuration for the whole server,
including tuning configurations in all web applications that are
deployed on such server.

In this scenario if Log4j2 is configured as JUL logging it means that
this allows to configure not only Tomcat itself, but also those other
applications and libraries that log to JUL directly.

A caveat with Log4j recipe is that you cannot turn off JUL logging.
The JUL logging still exists in Java and some web application or
library may be using it.  The Log4j recipe in our logging-howto says
to create an empty logging.properties file. That is a trick to silence
JUL, but not a real solution if something is really using it.

This is the reason why I would recommend plugging log4j2 into JUL. I
do not have real experience though. Thus far I prefer to use our JULI
(and plan to work on extending it if it ever does not meet my needs).

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1643937 - /tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java

[Mark Thomas]

On 08/12/2014 21:40, violet...@apache.org wrote:
> Author: violetagg
> Date: Mon Dec  8 21:40:06 2014
> New Revision: 1643937
> 
> URL: http://svn.apache.org/r1643937
> Log:
> Additional method was introduced to StandardRoot in order to be able to 
> extend classResources.
> 
> Modified:
> tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
> 
> Modified: tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java?rev=1643937&r1=1643936&r2=1643937&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java 
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/webresources/StandardRoot.java Mon 
> Dec  8 21:40:06 2014
> @@ -461,6 +461,11 @@ public class StandardRoot extends Lifecy
>  return classResources.toArray(new WebResourceSet[0]);
>  }
>  
> +protected void addClassResources(WebResourceSet webResourceSet) {
> +webResourceSet.setRoot(this);
> +classResources.add(webResourceSet);
> +}
> +

This looks suspicious too. What is the use case here?

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1643963 - in /tomcat/trunk: java/org/apache/catalina/filters/ExpiresFilter.java webapps/docs/config/filter.xml

[kkolinko]

Author: kkolinko
Date: Tue Dec  9 00:51:00 2014
New Revision: 1643963

URL: http://svn.apache.org/r1643963
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57331
Allow ExpiresFilter to use "year" as synonym for "years" in its configuration.
Update documentation to mention both "" and "s" duration unit names.
Fix minor formatting issue (Many lines in XML text were wrongly wrapped. 
because quote character was replaced by  and that broke wrapping 
algorithm.)

Modified:
tomcat/trunk/java/org/apache/catalina/filters/ExpiresFilter.java
tomcat/trunk/webapps/docs/config/filter.xml

Modified: tomcat/trunk/java/org/apache/catalina/filters/ExpiresFilter.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/ExpiresFilter.java?rev=1643963&r1=1643962&r2=1643963&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/filters/ExpiresFilter.java (original)
+++ tomcat/trunk/java/org/apache/catalina/filters/ExpiresFilter.java Tue Dec  9 
00:51:00 2014
@@ -1558,7 +1558,8 @@ public class ExpiresFilter extends Filte
 Integer.valueOf(amount), line));
 }
 DurationUnit durationUnit;
-if ("years".equalsIgnoreCase(currentToken)) {
+if ("year".equalsIgnoreCase(currentToken) ||
+"years".equalsIgnoreCase(currentToken)) {
 durationUnit = DurationUnit.YEAR;
 } else if ("month".equalsIgnoreCase(currentToken) ||
 "months".equalsIgnoreCase(currentToken)) {

Modified: tomcat/trunk/webapps/docs/config/filter.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/filter.xml?rev=1643963&r1=1643962&r2=1643963&view=diff
==
--- tomcat/trunk/webapps/docs/config/filter.xml (original)
+++ tomcat/trunk/webapps/docs/config/filter.xml Tue Dec  9 00:51:00 2014
@@ -325,7 +325,7 @@
 
 
 
-These HTTP headers are an instruction to the client about the 
document's
+These HTTP headers are an instruction to the client about the document's
 validity and persistence. If cached, the document may be fetched from the
 cache rather than from the source until this time has passed. After that, 
the
 cache copy is considered "expired" and invalid, and a new copy 
must
@@ -380,24 +380,24 @@
 
 
 
 where  is one of:
 
 
 access
-now (equivalent to 'access')
+now (equivalent to 'access')
 modification
 
 
@@ -407,13 +407,13 @@
  is one of:
 
 
-years
-months
-weeks
-days
-hours
-minutes
-seconds
+year, years
+month, months
+week, weeks
+day, days
+hour, hours
+minute, minutes
+second, seconds
 
 
 For example, any of the following directives can be used to make documents
@@ -435,18 +435,18 @@
  access plus 30 days
 ]]>
 
-The expiry time can be fine-tuned by adding several '
- ' clauses:
+The expiry time can be fine-tuned by adding several
+' ' clauses:
 
 
 
 
 Note that if you use a modification date based setting, the 
Expires
@@ -485,14 +485,13 @@ The expiry time can be fine-tuned by add
 
 ExpiresByType matching the exact content-type returned by
 HttpServletResponse.getContentType() possibly including the 
charset
-(e.g. 'text/xml;charset=UTF-8'),
+(e.g. 'text/xml;charset=UTF-8'),
 ExpiresByType matching the content-type without the 
charset if
-HttpServletResponse.getContentType() contains a charset (e.g. 
'
-text/xml;charset=UTF-8' -> 
'text/xml'),
+HttpServletResponse.getContentType() contains a charset (e.g.
+'text/xml;charset=UTF-8' -> 'text/xml'),
 ExpiresByType matching the major type (e.g. substring 
before
-'/') of 
HttpServletResponse.getContentType()
-(e.g. 'text/xml;charset=UTF-8' -> 
'text
-'),
+'/') of HttpServletResponse.getContentType()
+(e.g. 'text/xml;charset=UTF-8' -> 
'text'),
 ExpiresDefault
 
 
@@ -542,10 +541,10 @@ The expiry time can be fine-tuned by add
  
  
  The base time is either the last modification time of the file, or 
the time
- of the client's access to the document. Which should be used is
+ of the client's access to the document. Which should be used is
  specified by the  field; M 
means that the
- file's last modification time should be used as the base time, 
and
- A means the client's access time should be used. 
The duration
+ file's last modification time should be used as the base time, and
+ A means the client's access time should be used. The 
duration
  is expressed in seconds. A2592000 stands for
  access plus 30 days in alternate syntax.
  
@@ -553,10 +552,10 @@ The expiry time can be fine-t