[GUMP@vmgump]: Project tomcat-trunk-test-apr (in module tomcat-trunk) failed

2014-08-27 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-trunk-test-apr has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-trunk-test-apr :  Tomcat 8.x, a web server implementing the Java 
Servlet 3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
tomcat-native.tar.gz.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/logs-APR
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-trunk/output/test-tmp-APR/logs



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test-apr/gump_work/build_tomcat-trunk_tomcat-trunk-test-apr.html
Work Name: build_tomcat-trunk_tomcat-trunk-test-apr (Type: Build)
Work ended in a state of : Failed
Elapsed: 28 mins 39 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.12-SNAPSHOT.jar 
-Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.2-SNAPSHOT.jar
 -Dtest.reports=output/logs-APR 
-Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140828-native-src.tar.gz
 -Dexamples.sources.skip=true 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/P20140317-1600/ecj-P20140317-1600.jar
 -Dtest.apr.loc=/srv/gump/public/workspace/tomcat-native/dest-20140828/lib 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20140828.jar
 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20140828-native-src.tar.gz
 -Dtest.temp=output/test-tmp-APR -Dtest.accesslog=true -Dexecute.test.nio=false
  
-Dtest.openssl.path=/srv/gump/public/workspace/openssl/dest-20140828/bin/openssl
 -Dexecute.test.apr=true -Dexecute.test.bio=false -Dexecute.test.nio2=false 
-Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar
 
-Dhamcrest.jar=/srv/gump/public/workspace/hamcrest/build/hamcrest-all-20140828.jar
 -Dcglib.jar=/srv/gump/packages/cglib/cglib-nodep-2.2.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-trunk]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-trunk/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/websocket-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-storeconfig.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-j

[Bug 56896] if the url contains %, Tomcat connot receive the request.

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56896

chdyan <380994...@qq.com> changed:

   What|Removed |Added

Summary|if the url contains %,  |if the url contains %,
   |deploye tomcat servlet  |Tomcat connot receive the
   |cannot enter|request.
 OS||All

-- 
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 56896] New: if the url contains %, deploye tomcat servlet cannot enter

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56896

Bug ID: 56896
   Summary: if the url contains %, deploye tomcat servlet cannot
enter
   Product: Tomcat 8
   Version: trunk
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
  Assignee: dev@tomcat.apache.org
  Reporter: 380994...@qq.com

Using Tomcat 8.0.11, I occur a problem, if the url contains %, deploye tomcat
servlet cannot receive the request.
eg:the url is "http://localhost:8080/test/aaa%2F4";. 
"test" is my project name.request can not enter the tomcat that meas tomcat can
not receive this request. But I remove the '%', eg:
"http://localhost:8080/test/aaa2F4";. this request can be receive by tomcat  and
printed the words that I supoose. for example print the
url:"http://localhost:8080/test/aaa2F4";

-- 
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 56895] New: catalina.bat does not properly compose JAVA_OPTS

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56895

Bug ID: 56895
   Summary: catalina.bat does not properly compose JAVA_OPTS
   Product: Tomcat 7
   Version: 7.0.54
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Integration
  Assignee: dev@tomcat.apache.org
  Reporter: lucasthei...@apache.org

When composing JAVA_OPTS, the current bat script uses this approach:

set JAVA_OPTS=%JAVA_OPTS% %OTHER_STUFF%

However, this leads to issues if the existing JAVA_OPTS had some sort of escape
sequence in it.  For example, in my setenv.bat, I add some proxy info:

SET "JAVA_OPTS=-Dhttp.proxyHost=myproxy.localdomain
-Dhttp.nonProxyHosts=*.localdomain^|localhost^|appserver.localdomain"

Using the existing approach, the escape sequence ^| gets processed into |
leaving the next evaluation to treat it as a command pipe, which causes
immediate failure.

If instead you use this approach:

set "JAVA_OPTS=%JAVA_OPTS% %OTHER_STUFF%"

Then those escape sequences are preserved.  Here is the patch for version
7.0.54:

--- catalina.bat_ORIGINAL   2014-08-27 18:37:05.173641700 -0400
+++ catalina.bat2014-08-27 18:06:22.779721000 -0400
@@ -176,12 +176,12 @@
 if not exist "%CATALINA_BASE%\conf\logging.properties" goto noJuliConfig
 set
LOGGING_CONFIG=-Djava.util.logging.config.file="%CATALINA_BASE%\conf\logging.properties"
 :noJuliConfig
-set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%
+set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%"

 if not "%LOGGING_MANAGER%" == "" goto noJuliManager
 set
LOGGING_MANAGER=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 :noJuliManager
-set JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%
+set "JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%"

 rem - Execute The Requested Command
---

-- 
You are receiving this mail because:
You are the assignee for the bug.

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



Re: svn commit: r1620923 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread Christopher Schultz
Mark,

On 8/27/14, 1:33 PM, Mark Thomas wrote:
> On 27/08/2014 18:00, Christopher Schultz wrote:
>> Mark,
>>
>> On 8/27/14, 12:12 PM, Mark Thomas wrote:
>>> On 27/08/2014 17:05, schu...@apache.org wrote:
 Author: schultz
 Date: Wed Aug 27 16:05:38 2014
 New Revision: 1620923

 URL: http://svn.apache.org/r1620923
 Log:
 Added missing hashCode method.
>>>
>>> Two questions.
>>>
>>> 1. Why do you think this method is missing? I'm pretty sure (although
>>> I'm going to need to install it to check) that FindBugs is now going
>>> complain about a missing equals(XMLString) method.
>>
>> You're right. I was looking at equals(String) and jumping to the wrong
>> conclusion. What is your preference, here? Remove hashCode() or add
>> equals(Object)?
> 
> We don't need a custom hashcode() or equals() so my vote is for removing
> the hashcode method (preference is always to delete code if practical).
> 
>>> 2. Why were length and offset (both part of XMLString's state) not
>>> included in the hashcode calculation?
>>
>> Whoops. Depending upon your response to the above, I'll either correct
>> it or remove the method.
> 
> See above.

Reverted x 2

-chris

 Modified:
 tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

 Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
 URL: 
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620923&r1=1620922&r2=1620923&view=diff
 ==
 --- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
 +++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 
 27 16:05:38 2014
 @@ -25,6 +25,8 @@
  
  package org.apache.jasper.xmlparser;
  
 +import java.util.Arrays;
 +
  /**
   * This class is used as a structure to pass text contained in the 
 underlying
   * character buffer of the scanner. The offset and length fields allow the
 @@ -138,6 +140,11 @@ public class XMLString {
  //
  // Object methods
  //
 +@Override
 +public int hashCode()
 +{
 +return Arrays.hashCode(ch);
 +}
  
  /** Returns a string representation of this object. */
  @Override



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

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



signature.asc
Description: OpenPGP digital signature


svn commit: r1620959 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 19:02:18 2014
New Revision: 1620959

URL: http://svn.apache.org/r1620959
Log:
Reverted r1620924 after review.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Reverse-merged /tomcat/trunk:r1620923

Modified: tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620959&r1=1620958&r2=1620959&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed 
Aug 27 19:02:18 2014
@@ -25,8 +25,6 @@
 
 package org.apache.jasper.xmlparser;
 
-import java.util.Arrays;
-
 /**
  * This class is used as a structure to pass text contained in the underlying
  * character buffer of the scanner. The offset and length fields allow the
@@ -140,11 +138,6 @@ public class XMLString {
 //
 // Object methods
 //
-@Override
-public int hashCode()
-{
-return Arrays.hashCode(ch);
-}
 
 /** Returns a string representation of this object. */
 @Override



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



svn commit: r1620958 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 19:00:34 2014
New Revision: 1620958

URL: http://svn.apache.org/r1620958
Log:
Reverted r1620923 after review.

Modified:
tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620958&r1=1620957&r2=1620958&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
+++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 27 
19:00:34 2014
@@ -25,8 +25,6 @@
 
 package org.apache.jasper.xmlparser;
 
-import java.util.Arrays;
-
 /**
  * This class is used as a structure to pass text contained in the underlying
  * character buffer of the scanner. The offset and length fields allow the
@@ -140,11 +138,6 @@ public class XMLString {
 //
 // Object methods
 //
-@Override
-public int hashCode()
-{
-return Arrays.hashCode(ch);
-}
 
 /** Returns a string representation of this object. */
 @Override



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



Re: svn commit: r1620923 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread Mark Thomas
On 27/08/2014 18:00, Christopher Schultz wrote:
> Mark,
> 
> On 8/27/14, 12:12 PM, Mark Thomas wrote:
>> On 27/08/2014 17:05, schu...@apache.org wrote:
>>> Author: schultz
>>> Date: Wed Aug 27 16:05:38 2014
>>> New Revision: 1620923
>>>
>>> URL: http://svn.apache.org/r1620923
>>> Log:
>>> Added missing hashCode method.
>>
>> Two questions.
>>
>> 1. Why do you think this method is missing? I'm pretty sure (although
>> I'm going to need to install it to check) that FindBugs is now going
>> complain about a missing equals(XMLString) method.
> 
> You're right. I was looking at equals(String) and jumping to the wrong
> conclusion. What is your preference, here? Remove hashCode() or add
> equals(Object)?

We don't need a custom hashcode() or equals() so my vote is for removing
the hashcode method (preference is always to delete code if practical).

>> 2. Why were length and offset (both part of XMLString's state) not
>> included in the hashcode calculation?
> 
> Whoops. Depending upon your response to the above, I'll either correct
> it or remove the method.

See above.

Cheers,

Mark

> 
> Thanks,
> -chris
> 
>>> Modified:
>>> tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
>>>
>>> Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
>>> URL: 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620923&r1=1620922&r2=1620923&view=diff
>>> ==
>>> --- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
>>> +++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 27 
>>> 16:05:38 2014
>>> @@ -25,6 +25,8 @@
>>>  
>>>  package org.apache.jasper.xmlparser;
>>>  
>>> +import java.util.Arrays;
>>> +
>>>  /**
>>>   * This class is used as a structure to pass text contained in the 
>>> underlying
>>>   * character buffer of the scanner. The offset and length fields allow the
>>> @@ -138,6 +140,11 @@ public class XMLString {
>>>  //
>>>  // Object methods
>>>  //
>>> +@Override
>>> +public int hashCode()
>>> +{
>>> +return Arrays.hashCode(ch);
>>> +}
>>>  
>>>  /** Returns a string representation of this object. */
>>>  @Override
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
> 


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



Re: svn commit: r1620923 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread Christopher Schultz
Mark,

On 8/27/14, 12:12 PM, Mark Thomas wrote:
> On 27/08/2014 17:05, schu...@apache.org wrote:
>> Author: schultz
>> Date: Wed Aug 27 16:05:38 2014
>> New Revision: 1620923
>>
>> URL: http://svn.apache.org/r1620923
>> Log:
>> Added missing hashCode method.
> 
> Two questions.
> 
> 1. Why do you think this method is missing? I'm pretty sure (although
> I'm going to need to install it to check) that FindBugs is now going
> complain about a missing equals(XMLString) method.

You're right. I was looking at equals(String) and jumping to the wrong
conclusion. What is your preference, here? Remove hashCode() or add
equals(Object)?

> 2. Why were length and offset (both part of XMLString's state) not
> included in the hashcode calculation?

Whoops. Depending upon your response to the above, I'll either correct
it or remove the method.

Thanks,
-chris

>> Modified:
>> tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
>>
>> Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620923&r1=1620922&r2=1620923&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
>> +++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 27 
>> 16:05:38 2014
>> @@ -25,6 +25,8 @@
>>  
>>  package org.apache.jasper.xmlparser;
>>  
>> +import java.util.Arrays;
>> +
>>  /**
>>   * This class is used as a structure to pass text contained in the 
>> underlying
>>   * character buffer of the scanner. The offset and length fields allow the
>> @@ -138,6 +140,11 @@ public class XMLString {
>>  //
>>  // Object methods
>>  //
>> +@Override
>> +public int hashCode()
>> +{
>> +return Arrays.hashCode(ch);
>> +}
>>  
>>  /** Returns a string representation of this object. */
>>  @Override
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 



signature.asc
Description: OpenPGP digital signature


Re: svn commit: r1620923 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread Mark Thomas
On 27/08/2014 17:05, schu...@apache.org wrote:
> Author: schultz
> Date: Wed Aug 27 16:05:38 2014
> New Revision: 1620923
> 
> URL: http://svn.apache.org/r1620923
> Log:
> Added missing hashCode method.

Two questions.

1. Why do you think this method is missing? I'm pretty sure (although
I'm going to need to install it to check) that FindBugs is now going
complain about a missing equals(XMLString) method.

2. Why were length and offset (both part of XMLString's state) not
included in the hashcode calculation?

Mark


> 
> Modified:
> tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
> 
> Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620923&r1=1620922&r2=1620923&view=diff
> ==
> --- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
> +++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 27 
> 16:05:38 2014
> @@ -25,6 +25,8 @@
>  
>  package org.apache.jasper.xmlparser;
>  
> +import java.util.Arrays;
> +
>  /**
>   * This class is used as a structure to pass text contained in the underlying
>   * character buffer of the scanner. The offset and length fields allow the
> @@ -138,6 +140,11 @@ public class XMLString {
>  //
>  // Object methods
>  //
> +@Override
> +public int hashCode()
> +{
> +return Arrays.hashCode(ch);
> +}
>  
>  /** Returns a string representation of this object. */
>  @Override
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



svn commit: r1620924 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 16:06:41 2014
New Revision: 1620924

URL: http://svn.apache.org/r1620924
Log:
Back-ported r1620923
Added missing hashCode method.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1620923

Modified: tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620924&r1=1620923&r2=1620924&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed 
Aug 27 16:06:41 2014
@@ -25,6 +25,8 @@
 
 package org.apache.jasper.xmlparser;
 
+import java.util.Arrays;
+
 /**
  * This class is used as a structure to pass text contained in the underlying
  * character buffer of the scanner. The offset and length fields allow the
@@ -138,6 +140,11 @@ public class XMLString {
 //
 // Object methods
 //
+@Override
+public int hashCode()
+{
+return Arrays.hashCode(ch);
+}
 
 /** Returns a string representation of this object. */
 @Override



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



svn commit: r1620923 - /tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 16:05:38 2014
New Revision: 1620923

URL: http://svn.apache.org/r1620923
Log:
Added missing hashCode method.

Modified:
tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java

Modified: tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java?rev=1620923&r1=1620922&r2=1620923&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java (original)
+++ tomcat/trunk/java/org/apache/jasper/xmlparser/XMLString.java Wed Aug 27 
16:05:38 2014
@@ -25,6 +25,8 @@
 
 package org.apache.jasper.xmlparser;
 
+import java.util.Arrays;
+
 /**
  * This class is used as a structure to pass text contained in the underlying
  * character buffer of the scanner. The offset and length fields allow the
@@ -138,6 +140,11 @@ public class XMLString {
 //
 // Object methods
 //
+@Override
+public int hashCode()
+{
+return Arrays.hashCode(ch);
+}
 
 /** Returns a string representation of this object. */
 @Override



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



svn commit: r1620918 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 15:53:36 2014
New Revision: 1620918

URL: http://svn.apache.org/r1620918
Log:
Back-ported r1620917
Moved resource-freeing code from finalize() to breakdown()
Have finalize() call breakdown() instead of vice-versa.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)

tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1620917

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=1620918&r1=1620917&r2=1620918&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Wed Aug 27 15:53:36 2014
@@ -338,16 +338,6 @@ public abstract class AbstractReplicated
 }
 
 public void breakdown() {
-// TODO: Invert the call semantics between between breakdown() and 
finalize()
-try {
-finalize();
-} catch (Throwable t) {
-log.error("Call to finalize() failed", t);
-}
-}
-
-@Override
-public void finalize() throws Throwable {
 if (this.rpcChannel != null) {
 this.rpcChannel.breakdown();
 }
@@ -363,8 +353,15 @@ public abstract class AbstractReplicated
 innerMap.clear();
 this.stateTransferred = false;
 this.externalLoaders = null;
+}
 
-super.finalize();
+@Override
+public void finalize() throws Throwable {
+try {
+breakdown();
+} finally {
+super.finalize();
+}
 }
 
 @Override



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



svn commit: r1620917 - /tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 15:52:07 2014
New Revision: 1620917

URL: http://svn.apache.org/r1620917
Log:
Moved resource-freeing code from finalize() to breakdown()
Have finalize() call breakdown() instead of vice-versa.

Modified:

tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=1620917&r1=1620916&r2=1620917&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java 
Wed Aug 27 15:52:07 2014
@@ -329,16 +329,6 @@ public abstract class AbstractReplicated
 }
 
 public void breakdown() {
-// TODO: Invert the call semantics between between breakdown() and 
finalize()
-try {
-finalize();
-} catch (Throwable t) {
-log.error("Call to finalize() failed", t);
-}
-}
-
-@Override
-public void finalize() throws Throwable {
 if (this.rpcChannel != null) {
 this.rpcChannel.breakdown();
 }
@@ -354,8 +344,15 @@ public abstract class AbstractReplicated
 innerMap.clear();
 this.stateTransferred = false;
 this.externalLoaders = null;
+}
 
-super.finalize();
+@Override
+public void finalize() throws Throwable {
+try {
+breakdown();
+} finally {
+super.finalize();
+}
 }
 
 @Override



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



svn commit: r1620916 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/tribes/group/ java/org/apache/catalina/tribes/tipis/ java/org/apache/catalina/tribes/transport/bio/ java/org/apache/catalin

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 15:49:27 2014
New Revision: 1620916

URL: http://svn.apache.org/r1620916
Log:
Back-port 1620915
Add super.finalize to finalize() methods that were missing them.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java

tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java

tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java

tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1620915

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1620916&r1=1620915&r2=1620916&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java 
Wed Aug 27 15:49:27 2014
@@ -175,8 +175,9 @@ public class RpcChannel implements Chann
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 breakdown();
+super.finalize();
 }
 
 @Override

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=1620916&r1=1620915&r2=1620916&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
 Wed Aug 27 15:49:27 2014
@@ -338,11 +338,16 @@ public abstract class AbstractReplicated
 }
 
 public void breakdown() {
-finalize();
+// TODO: Invert the call semantics between between breakdown() and 
finalize()
+try {
+finalize();
+} catch (Throwable t) {
+log.error("Call to finalize() failed", t);
+}
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 if (this.rpcChannel != null) {
 this.rpcChannel.breakdown();
 }
@@ -358,6 +363,8 @@ public abstract class AbstractReplicated
 innerMap.clear();
 this.stateTransferred = false;
 this.externalLoaders = null;
+
+super.finalize();
 }
 
 @Override

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java?rev=1620916&r1=1620915&r2=1620916&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
 Wed Aug 27 15:49:27 2014
@@ -135,8 +135,9 @@ public class MultipointBioSender extends
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 try {disconnect(); }catch ( Exception e){/* Ignore */}
+super.finalize();
 }
 
 

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java?rev=1620916&r1=1620915&r2=1620916&view=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
 Wed Aug 27 15:49:27 2014
@@ -291,7 +291,7 @@ public class ParallelNioSender extends A
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 try {disconnect(); }catch ( Exception e){/*Ignore*/}
 try {
 selector.close();
@@ -300,6 +300,7 @@ public class ParallelNioSender extends A
 log.debug("Failed to close selector", e);
 }
 }
+super.finalize();
 }
 
 @Override

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/

svn commit: r1620915 - in /tomcat/trunk/java/org/apache: catalina/tribes/group/ catalina/tribes/tipis/ catalina/tribes/transport/bio/ catalina/tribes/transport/nio/ tomcat/jni/socket/

2014-08-27 Thread schultz
Author: schultz
Date: Wed Aug 27 15:42:25 2014
New Revision: 1620915

URL: http://svn.apache.org/r1620915
Log:
Add super.finalize to finalizers missing those calls.

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java

tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java

tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java

tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
tomcat/trunk/java/org/apache/tomcat/jni/socket/AprSocketContext.java

Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1620915&r1=1620914&r2=1620915&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Aug 
27 15:42:25 2014
@@ -175,8 +175,9 @@ public class RpcChannel implements Chann
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 breakdown();
+super.finalize();
 }
 
 @Override

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java?rev=1620915&r1=1620914&r2=1620915&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/tipis/AbstractReplicatedMap.java 
Wed Aug 27 15:42:25 2014
@@ -329,11 +329,16 @@ public abstract class AbstractReplicated
 }
 
 public void breakdown() {
-finalize();
+// TODO: Invert the call semantics between between breakdown() and 
finalize()
+try {
+finalize();
+} catch (Throwable t) {
+log.error("Call to finalize() failed", t);
+}
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 if (this.rpcChannel != null) {
 this.rpcChannel.breakdown();
 }
@@ -349,6 +354,8 @@ public abstract class AbstractReplicated
 innerMap.clear();
 this.stateTransferred = false;
 this.externalLoaders = null;
+
+super.finalize();
 }
 
 @Override

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java?rev=1620915&r1=1620914&r2=1620915&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/transport/bio/MultipointBioSender.java
 Wed Aug 27 15:42:25 2014
@@ -125,8 +125,9 @@ public class MultipointBioSender extends
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 try {disconnect(); }catch ( Exception e){/* Ignore */}
+super.finalize();
 }
 
 

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java?rev=1620915&r1=1620914&r2=1620915&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/ParallelNioSender.java
 Wed Aug 27 15:42:25 2014
@@ -302,7 +302,7 @@ public class ParallelNioSender extends A
 }
 
 @Override
-public void finalize() {
+public void finalize() throws Throwable {
 try {disconnect(); }catch ( Exception e){/*Ignore*/}
 try {
 selector.close();
@@ -311,6 +311,7 @@ public class ParallelNioSender extends A
 log.debug("Failed to close selector", e);
 }
 }
+super.finalize();
 }
 
 @Override

Modified: tomcat/trunk/java/org/apache/tomcat/jni/socket/AprSocketContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/jni/socket/AprSocketContext.java?rev=1620915&r1=1620914&r2=1620915&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/jni/socket/AprSocketContext.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/jni/socket/AprSocketContext.java Wed 
Aug 27 15:42:25 2014
@@ -494,7 +494,7 @@ public class AprSocketContext {
  * closed, but this seems si

svn commit: r1620903 - in /tomcat/trunk: java/org/apache/jasper/compiler/Compiler.java java/org/apache/jasper/compiler/Generator.java java/org/apache/jasper/servlet/JspServletWrapper.java test/org/apa

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 14:28:14 2014
New Revision: 1620903

URL: http://svn.apache.org/r1620903
Log:
Rework fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=56568

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
tomcat/trunk/test/org/apache/jasper/servlet/TestJspServlet.java

Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1620903&r1=1620902&r2=1620903&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Wed Aug 27 
14:28:14 2014
@@ -255,13 +255,6 @@ public abstract class Compiler {
 // to be GC'd and save memory.
 ctxt.setWriter(null);
 
-if (jsw != null) {
-// Need to know if the JSP is an error page at runtime to 
determine
-// which HTTP methods are permitted. Error pages permit any. 
Normal
-// pages only permit GET, POST or HEAD.
-jsw.setErrorPage(pageInfo.isErrorPage());
-}
-
 if (log.isDebugEnabled()) {
 t4 = System.currentTimeMillis();
 log.debug("Generated " + javaFileName + " total=" + (t4 - t1)

Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=1620903&r1=1620902&r2=1620903&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Wed Aug 27 
14:28:14 2014
@@ -643,6 +643,20 @@ class Generator {
 out.pushIndent();
 out.println();
 
+// Method check
+if (!pageInfo.isErrorPage()) {
+out.println("final java.lang.String _jspx_method = 
request.getMethod();");
+out.print("if (!\"GET\".equals(_jspx_method) && 
!\"POST\".equals(_jspx_method) && !\"HEAD\".equals(_jspx_method) && ");
+
out.println("!javax.servlet.DispatcherType.ERROR.equals(request.getDispatcherType()))
 {");
+out.pushIndent();
+
out.print("response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED, ");
+out.println("\"" + 
Localizer.getMessage("jsp.error.servlet.invalid.method") + "\");");
+out.println("return;");
+out.popIndent();
+out.println("}");
+out.println();
+}
+
 // Local variable declarations
 out.printil("final javax.servlet.jsp.PageContext pageContext;");
 

Modified: tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java?rev=1620903&r1=1620902&r2=1620903&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java 
(original)
+++ tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java Wed Aug 
27 14:28:14 2014
@@ -22,7 +22,6 @@ import java.io.IOException;
 import java.util.HashMap;
 import java.util.Map;
 
-import javax.servlet.DispatcherType;
 import javax.servlet.RequestDispatcher;
 import javax.servlet.Servlet;
 import javax.servlet.ServletConfig;
@@ -104,7 +103,6 @@ public class JspServletWrapper {
 private final boolean unloadAllowed;
 private final boolean unloadByCount;
 private final boolean unloadByIdle;
-private boolean errorPage;
 
 /*
  * JspServletWrapper for JSP pages.
@@ -421,20 +419,6 @@ public class JspServletWrapper {
 }
 }
 
-String method = request.getMethod();
-
-if (!"GET".equals(method) && !"POST".equals(method) && 
!"HEAD".equals(method) &&
-!DispatcherType.ERROR.equals(request.getDispatcherType()) 
&&
-!isErrorPage()) {
-// Specification states behaviour is undefined
-// Jasper opts to reject any other verbs, partly as they are
-// unlikely to make sense in a JSP context and partly to 
protect
-// against verb tampering
-response.sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED,
-
Localizer.getMessage("jsp.error.servlet.invalid.method"));
-return;
-}
-
 /*
  * (4) Service request
  */
@@ -601,14 +585,4 @@ public class JspServletWrapper {
 return new JasperException(ex);
 }
 }
-
-
-public void se

Re: Coverity static analysis scanning

2014-08-27 Thread Rémy Maucherat
2014-08-26 11:20 GMT+02:00 Mark Thomas :

> All,
>
> I have been pinged off-list by Coverity to say that they have set up
> Tomcat with a free account with their static code analysis service.
>
> I think I have the ability to send invitations so if anyone wants to
> take a look at the results, just reply here.
>
> I have taken a quick look and they do appear to have found some valid
> threading issues. There are ~350 issues in total and I don't yet have a
> feel for the false positive rate.
>
> Ok, so since there was so much noise about it I had a look. I am not quite
convinced (= I don't plan to actually fix anything meaningful), but at
least it does seem to attempt to do something useful.

Rémy


[Bug 56825] AuthenticatorBase not looking for Coyote Request certificate

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56825

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Konstantin Kolinko  ---
REOPENing for Tomcat 7.
As discussed in "Re r1617445" on dev, the change trigger re-authentication for
webapps that do not need it.

The fix in Tomcat 8 is r1617461 but it has not been backported to Tomcat 7 yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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



Re: svn commit: r1620596 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/servlet/ test/org/apache/jasper/servlet/ test/webapp/jsp/ webapps/docs/

2014-08-27 Thread Mark Thomas
On 27/08/2014 13:34, Konstantin Kolinko wrote:
> 2014-08-27 13:06 GMT+04:00 Mark Thomas :
>> On 26/08/2014 23:16, Konstantin Kolinko wrote:
>>> 2014-08-26 17:32 GMT+04:00  :
 Author: markt
 Date: Tue Aug 26 13:32:45 2014
 New Revision: 1620596

 URL: http://svn.apache.org/r1620596
 Log:
 Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56568
 Enable any HTTP method to be used to request a JSP page that has the 
 isErrorPage page directive set to true.

 Added:
 tomcat/trunk/test/webapp/jsp/error.jsp   (with props)
 Modified:
 tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
 tomcat/trunk/java/org/apache/jasper/servlet/JspServlet.java
 tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
 tomcat/trunk/test/org/apache/jasper/servlet/TestJspServlet.java
 tomcat/trunk/webapps/docs/changelog.xml
 Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
 URL: 
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1620596&r1=1620595&r2=1620596&view=diff
 ==
 --- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
 +++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Aug 26 
 13:32:45 2014
 @@ -255,6 +255,11 @@ public abstract class Compiler {
  // to be GC'd and save memory.
  ctxt.setWriter(null);

 +// Need to know if the JSP is an error page at runtime to 
 determine
 +// which HTTP methods are permitted. Error pages permit any. 
 Normal
 +// pages only permit GET, POST or HEAD.
 +jsw.setErrorPage(pageInfo.isErrorPage());
 +
>>>
>>> Apparently this causes org.apache.jasper.TestJspC to fail with many NPEs,
>>> as noted by  Gump in tomcat-trunk-test-nio:
>>>
>>> [junit] java.lang.NullPointerException
>>> [junit] at 
>>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:261)
>>> [junit] at 
>>> org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
>>> [junit] at org.apache.jasper.JspC.processFile(JspC.java:1217)
>>>
>>> All other test cases completed successfully.
>>
>> Thanks. Fixed.
> 
> I think that method is a wrong place to configure a JspServletWrapper.

I think you are right. I was trying fail early but I think the check is
going to need to be lower - probably in the generated code.

> The generateJava() method generates java text for a JSP page.  It will
> be skipped if there is no need to recompile the page.
> E.g. if web application was reloaded and loads a previously compiled class.

That is one failure mode.

> I also wonder how this feature works with precompiled JSPs that are
> decalred as s in web.xml.

I suspect that is another.

I'll take another look.

Mark


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



[Bug 56890] getRealPath returns null

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890

--- Comment #2 from Mark Thomas  ---
I'm leaning towards resolving this as invalid.

While the spec and the Javadoc could be clearer, it seems pretty obvious that a
'virtual path' is 'servletPath + pathInfo' along the lines of section 3.5 of
the Servlet spec.

Therefore, requiring that the virtual path is either empty or starts with '/'
seems reasonable.

It is not unusual for one major verison of Tomcat to interpret a specification
more strictly than the previous major version. Such changes are to be expected
across major versions and certainly do not qualify as bugs. If these changes
are causing problems, then they can be added to the migration guide.

An argument could be made that the virtual path, if it doesn't start with '/',
should be taken as being relative to the ServletContext root - i.e. append '/'
and then process it. I'm not convinced that that argument is valid since there
is nothing I see in the specs or the Javadoc to support it.

-- 
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 56890] getRealPath returns null

2014-08-27 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56890

--- Comment #1 from Konstantin Kolinko  ---
Resource paths are expected to start with a "/" (per javadoc of
ServletContext.getResource()). [1]

The behaviour in Tomcat 8 is caused by a more strict underlying Resources
implementation.

That said,
- I would expect "strict compliance" option (or more specifically
GET_RESOURCE_REQUIRE_SLASH option) to control this behaviour both in this and
in older versions. Apparently it is not so. [2]

- I wonder whether passing "" instead of "/" to getRealPath("") is valid.


[1]
http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getResource%28java.lang.String%29

[2]
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification

-- 
You are receiving this mail because:
You are the assignee for the bug.

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



Re: svn commit: r1620596 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/servlet/ test/org/apache/jasper/servlet/ test/webapp/jsp/ webapps/docs/

2014-08-27 Thread Konstantin Kolinko
2014-08-27 13:06 GMT+04:00 Mark Thomas :
> On 26/08/2014 23:16, Konstantin Kolinko wrote:
>> 2014-08-26 17:32 GMT+04:00  :
>>> Author: markt
>>> Date: Tue Aug 26 13:32:45 2014
>>> New Revision: 1620596
>>>
>>> URL: http://svn.apache.org/r1620596
>>> Log:
>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56568
>>> Enable any HTTP method to be used to request a JSP page that has the 
>>> isErrorPage page directive set to true.
>>>
>>> Added:
>>> tomcat/trunk/test/webapp/jsp/error.jsp   (with props)
>>> Modified:
>>> tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
>>> tomcat/trunk/java/org/apache/jasper/servlet/JspServlet.java
>>> tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
>>> tomcat/trunk/test/org/apache/jasper/servlet/TestJspServlet.java
>>> tomcat/trunk/webapps/docs/changelog.xml
>>> Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
>>> URL: 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1620596&r1=1620595&r2=1620596&view=diff
>>> ==
>>> --- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
>>> +++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Aug 26 
>>> 13:32:45 2014
>>> @@ -255,6 +255,11 @@ public abstract class Compiler {
>>>  // to be GC'd and save memory.
>>>  ctxt.setWriter(null);
>>>
>>> +// Need to know if the JSP is an error page at runtime to 
>>> determine
>>> +// which HTTP methods are permitted. Error pages permit any. 
>>> Normal
>>> +// pages only permit GET, POST or HEAD.
>>> +jsw.setErrorPage(pageInfo.isErrorPage());
>>> +
>>
>> Apparently this causes org.apache.jasper.TestJspC to fail with many NPEs,
>> as noted by  Gump in tomcat-trunk-test-nio:
>>
>> [junit] java.lang.NullPointerException
>> [junit] at 
>> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:261)
>> [junit] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
>> [junit] at org.apache.jasper.JspC.processFile(JspC.java:1217)
>>
>> All other test cases completed successfully.
>
> Thanks. Fixed.

I think that method is a wrong place to configure a JspServletWrapper.

The generateJava() method generates java text for a JSP page.  It will
be skipped if there is no need to recompile the page.
E.g. if web application was reloaded and loads a previously compiled class.

I also wonder how this feature works with precompiled JSPs that are
decalred as s in web.xml.

Best regards,
Konstantin Kolinko

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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Mark Thomas
On 27/08/2014 10:58, Mark Thomas wrote:
> On 27/08/2014 10:38, Konstantin Kolinko wrote:
>> 2014-08-27 13:29 GMT+04:00 Mark Thomas :

>>>
>>> Bad news: The issue is that if there is a chance of UTF-8 in the header
>>> then you can't simply split the header into individual cookies based on
>>> the separator byte since you can't tell (without decoding to characters)
>>> if a byte represents the separator or is part of a sequence of several
>>> bytes representing some other character.
>>>
>>
>> You can. All separator bytes are 7-bit US-ASCII.
>>
>> BTW, There is also a feature in UTF-8 that you can split it into
>> characters without actually decoding them.
>>
>> I mean "Character boundaries are easily found from anywhere in an
>> octet stream." as said in "1. Introduction" of
>> http://tools.ietf.org/html/rfc3629
> 
> Doh. Thanks for the correction. That gives us rather more options (if we
> want/need them).
> 
> I had in the back of my mind an old UTF-8 related security issue where
> multi-byte characters were being incorrectly processed and the remaining
> bytes were incorrectly being treated single byte characters in the range
> 0-127. I need to re-read through that issue to remind myself exactly
> what was going on as with UTF-8 that simply should not be possible.

For the record it was CVE-2008-2938 and what was happening was that a
character that should have been encoded in 1 byte was encoded in
multiple bytes (so the checks for that character didn't see it) and the
UTF-8 decoder at the time failed to reject it as it was required it do
by the spec.

Mark


> On a related topic... Since ISO-8859-1 is valid for use in a cookie
> value (BZ 55917) we are going to have to provide an option somewhere to
> select the encoding to use to decode cookie values.
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



svn commit: r1620855 - in /tomcat/site/trunk: docs/whoweare.html xdocs/whoweare.xml

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 10:20:31 2014
New Revision: 1620855

URL: http://svn.apache.org/r1620855
Log:
Move Ian Darwin to emeritus at his request

Modified:
tomcat/site/trunk/docs/whoweare.html
tomcat/site/trunk/xdocs/whoweare.xml

Modified: tomcat/site/trunk/docs/whoweare.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whoweare.html?rev=1620855&r1=1620854&r2=1620855&view=diff
==
--- tomcat/site/trunk/docs/whoweare.html (original)
+++ tomcat/site/trunk/docs/whoweare.html Wed Aug 27 10:20:31 2014
@@ -198,7 +198,7 @@
 The Apache Tomcat Project operates on a meritocracy: the more you do,
 the more responsibility you will obtain. This page lists all of the
 people who have gone the extra mile and are Committers or members of
-the Project Management Committee. If you would like to help, please
+the Project Management Committee (PMC). If you would like to help, please
 see the overview on getting
 involved.
 
@@ -229,7 +229,7 @@ A complete list of all the Apache Commit
 
 
 
-Project Management Committee
+PMC Members & Committers
 
 
 
@@ -263,12 +263,6 @@ A complete list of all the Apache Commit
 
 
 
-Ian Darwin (idarwin at apache.org)
-
-
-
-
-
 Keiichi Fujino (kfujino at apache.org)
 
 
@@ -402,6 +396,24 @@ open-source projects: you can read more 
 
 
 
+Emeritus PMC members
+
+
+
+
+http://www.apache.org/foundation/glossary.html#Emeritus";>
+Emeritus is defined in the Apache glossary.
+
+
+
+
+
+Ian Darwin (idarwin at apache.org)
+
+
+
+
+
 Emeritus Committers
 
 

Modified: tomcat/site/trunk/xdocs/whoweare.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/whoweare.xml?rev=1620855&r1=1620854&r2=1620855&view=diff
==
--- tomcat/site/trunk/xdocs/whoweare.xml (original)
+++ tomcat/site/trunk/xdocs/whoweare.xml Wed Aug 27 10:20:31 2014
@@ -12,7 +12,7 @@
 The Apache Tomcat Project operates on a meritocracy: the more you do,
 the more responsibility you will obtain. This page lists all of the
 people who have gone the extra mile and are Committers or members of
-the Project Management Committee. If you would like to help, please
+the Project Management Committee (PMC). If you would like to help, please
 see the overview on getting
 involved.
 
@@ -40,7 +40,7 @@ A complete list of all the Apache Commit
 
 
 
-
+
 
 PMC Chair
 Mladen Turk (mturk at apache.org)
@@ -57,9 +57,6 @@ A complete list of all the Apache Commit
 Jean-Frederic Clere (jfclere at apache.org)
 
 
-Ian Darwin (idarwin at apache.org)
-
-
 Keiichi Fujino (kfujino at apache.org)
 
 
@@ -130,6 +127,16 @@ open-source projects: you can read more 
 
 
 
+
+
+http://www.apache.org/foundation/glossary.html#Emeritus";>
+Emeritus is defined in the Apache glossary.
+
+
+Ian Darwin (idarwin at apache.org)
+
+
+
 
 
 



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



svn commit: r1620854 - in /tomcat/site/trunk: docs/whoweare.html xdocs/whoweare.xml

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 10:16:12 2014
New Revision: 1620854

URL: http://svn.apache.org/r1620854
Log:
Alphabetical order by surname

Modified:
tomcat/site/trunk/docs/whoweare.html
tomcat/site/trunk/xdocs/whoweare.xml

Modified: tomcat/site/trunk/docs/whoweare.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whoweare.html?rev=1620854&r1=1620853&r2=1620854&view=diff
==
--- tomcat/site/trunk/docs/whoweare.html (original)
+++ tomcat/site/trunk/docs/whoweare.html Wed Aug 27 10:16:12 2014
@@ -360,6 +360,12 @@ A complete list of all the Apache Commit
 
 
 
+William A. Rowe Jr. (wrowe at apache.org)
+
+
+
+
+
 Christopher Schultz (schultz at apache.org)
 
 
@@ -395,9 +401,6 @@ open-source projects: you can read more 
 
 
 
-
-William A. Rowe Jr. (wrowe at apache.org)
-
 
 Emeritus Committers
 

Modified: tomcat/site/trunk/xdocs/whoweare.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/whoweare.xml?rev=1620854&r1=1620853&r2=1620854&view=diff
==
--- tomcat/site/trunk/xdocs/whoweare.xml (original)
+++ tomcat/site/trunk/xdocs/whoweare.xml Wed Aug 27 10:16:12 2014
@@ -106,6 +106,9 @@ A complete list of all the Apache Commit
 Peter Rossbach (pero at apache.org)
 
 
+William A. Rowe Jr. (wrowe at apache.org)
+
+
 Christopher Schultz (schultz at apache.org)
 
 
@@ -125,9 +128,6 @@ open-source projects: you can read more 
 
 Tim Whittington (timw at apache.org)
 
-
-William A. Rowe Jr. (wrowe at apache.org)
-
 
 
 



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



svn commit: r1620849 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java

2014-08-27 Thread remm
Author: remm
Date: Wed Aug 27 10:09:42 2014
New Revision: 1620849

URL: http://svn.apache.org/r1620849
Log:
Simplify.

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java?rev=1620849&r1=1620848&r2=1620849&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Aug 27 
10:09:42 2014
@@ -1092,8 +1092,6 @@ public class Nio2Endpoint extends Abstra
 closeSocket(socket, SocketStatus.ERROR);
 if (useCaches && running && !paused) {
 nioChannels.push(socket.getSocket());
-}
-if (useCaches && running && !paused) {
 socketWrapperCache.push((Nio2SocketWrapper) 
socket);
 }
 } else if (state == SocketState.UPGRADING) {
@@ -1105,8 +1103,6 @@ public class Nio2Endpoint extends Abstra
 closeSocket(socket, SocketStatus.DISCONNECT);
 if (useCaches && running && !paused) {
 nioChannels.push(socket.getSocket());
-}
-if (useCaches && running && !paused) {
 socketWrapperCache.push(((Nio2SocketWrapper) socket));
 }
 }



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



svn commit: r1620848 - /tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java

2014-08-27 Thread remm
Author: remm
Date: Wed Aug 27 10:08:32 2014
New Revision: 1620848

URL: http://svn.apache.org/r1620848
Log:
Drop leftover useless null checks. (now joining the club of people doing 
pointless commits ...)

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java?rev=1620848&r1=1620847&r2=1620848&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Aug 27 
10:08:32 2014
@@ -1093,7 +1093,7 @@ public class Nio2Endpoint extends Abstra
 if (useCaches && running && !paused) {
 nioChannels.push(socket.getSocket());
 }
-if (useCaches && running && !paused && socket != null) 
{
+if (useCaches && running && !paused) {
 socketWrapperCache.push((Nio2SocketWrapper) 
socket);
 }
 } else if (state == SocketState.UPGRADING) {
@@ -1106,7 +1106,7 @@ public class Nio2Endpoint extends Abstra
 if (useCaches && running && !paused) {
 nioChannels.push(socket.getSocket());
 }
-if (useCaches && running && !paused && socket != null) {
+if (useCaches && running && !paused) {
 socketWrapperCache.push(((Nio2SocketWrapper) socket));
 }
 }



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



Re: Coverity static analysis scanning

2014-08-27 Thread Henri Gomez
Fabrice Belingard, ASFer is working for Sonar.
I add him in loop so he could give us more informations

2014-08-27 11:45 GMT+02:00 Mark Thomas :
> On 26/08/2014 22:52, Henri Gomez wrote:
>> Hi all
>>
>> Are you aware SonarQube is analysing Tomcat in Nemo for years ?
>>
>>
>> http://nemo.sonarqube.org/dashboard/index/50544
>>
>> 310 Blocker issues, 121 Critical issues.
>
> I took a quick look. The first 60 or so blocker issues I looked at were
> all false positives triggered by us catching Throwable for good reasons.
> Can we get a login to this system to make them as false positives?
>
> Mark
>
>
>>
>> Wondering if Coverity will provides more informations than SonarQube ?
>>
>> BTW, SonarQube is analysing major ASF projects for a long time now :)
>>
>>
>> 2014-08-26 11:20 GMT+02:00 Mark Thomas :
>>> All,
>>>
>>> I have been pinged off-list by Coverity to say that they have set up
>>> Tomcat with a free account with their static code analysis service.
>>>
>>> I think I have the ability to send invitations so if anyone wants to
>>> take a look at the results, just reply here.
>>>
>>> I have taken a quick look and they do appear to have found some valid
>>> threading issues. There are ~350 issues in total and I don't yet have a
>>> feel for the false positive rate.
>>>
>>> Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Mark Thomas
On 27/08/2014 10:38, Konstantin Kolinko wrote:
> 2014-08-27 13:29 GMT+04:00 Mark Thomas :
>>>
>>
>> Bad news: The issue is that if there is a chance of UTF-8 in the header
>> then you can't simply split the header into individual cookies based on
>> the separator byte since you can't tell (without decoding to characters)
>> if a byte represents the separator or is part of a sequence of several
>> bytes representing some other character.
>>
> 
> You can. All separator bytes are 7-bit US-ASCII.
> 
> BTW, There is also a feature in UTF-8 that you can split it into
> characters without actually decoding them.
> 
> I mean "Character boundaries are easily found from anywhere in an
> octet stream." as said in "1. Introduction" of
> http://tools.ietf.org/html/rfc3629

Doh. Thanks for the correction. That gives us rather more options (if we
want/need them).

I had in the back of my mind an old UTF-8 related security issue where
multi-byte characters were being incorrectly processed and the remaining
bytes were incorrectly being treated single byte characters in the range
0-127. I need to re-read through that issue to remind myself exactly
what was going on as with UTF-8 that simply should not be possible.

On a related topic... Since ISO-8859-1 is valid for use in a cookie
value (BZ 55917) we are going to have to provide an option somewhere to
select the encoding to use to decode cookie values.

Mark


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



Re: Coverity static analysis scanning

2014-08-27 Thread Mark Thomas
On 26/08/2014 22:52, Henri Gomez wrote:
> Hi all
> 
> Are you aware SonarQube is analysing Tomcat in Nemo for years ?
> 
> 
> http://nemo.sonarqube.org/dashboard/index/50544
> 
> 310 Blocker issues, 121 Critical issues.

I took a quick look. The first 60 or so blocker issues I looked at were
all false positives triggered by us catching Throwable for good reasons.
Can we get a login to this system to make them as false positives?

Mark


> 
> Wondering if Coverity will provides more informations than SonarQube ?
> 
> BTW, SonarQube is analysing major ASF projects for a long time now :)
> 
> 
> 2014-08-26 11:20 GMT+02:00 Mark Thomas :
>> All,
>>
>> I have been pinged off-list by Coverity to say that they have set up
>> Tomcat with a free account with their static code analysis service.
>>
>> I think I have the ability to send invitations so if anyone wants to
>> take a look at the results, just reply here.
>>
>> I have taken a quick look and they do appear to have found some valid
>> threading issues. There are ~350 issues in total and I don't yet have a
>> feel for the false positive rate.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Konstantin Kolinko
2014-08-27 13:29 GMT+04:00 Mark Thomas :
>>
>
> Bad news: The issue is that if there is a chance of UTF-8 in the header
> then you can't simply split the header into individual cookies based on
> the separator byte since you can't tell (without decoding to characters)
> if a byte represents the separator or is part of a sequence of several
> bytes representing some other character.
>

You can. All separator bytes are 7-bit US-ASCII.

BTW, There is also a feature in UTF-8 that you can split it into
characters without actually decoding them.

I mean "Character boundaries are easily found from anywhere in an
octet stream." as said in "1. Introduction" of
http://tools.ietf.org/html/rfc3629

Best regards,
Konstantin Kolinko

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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Mark Thomas
On 26/08/2014 23:09, Rémy Maucherat wrote:
> 2014-08-26 21:53 GMT+02:00 Mark Thomas :
> 
>> One of the aims of the proposed cookie changes [1] was to deal with the
>> HTML 5 changes that mean UTF-8 can appear in cookie headers.
>>
>> This has some potentially large implications for Tomcat.
>>
>> Currently, Tomcat handles cookies as MessageBytes, processing everything
>> in bytes and only converting to String when necessary. This is largely
>> possible because of the assumption that everything is ASCII.
>>
>> Introduce UTF-8 and processing everything in bytes gets a whole lot
>> harder. You essentially have to decode to UTF-8 to ensure that you have
>> valid data - at a which point why not just use Strings anyway?
>>
>> I am currently leaning towards removing a lot of the current cookie
>> header caching  recycling and doing something along the following lines:
>> - Lazy parsing as currently (but unless cookie based session tracking is
>>   disabled this is going to run on every request)
>> - Convert headers to UTF-8 strings
>> - Parse them with a new parser along the lines of o.a.t.u.http.parser
>> - Have that parser return an array of javax.servlet.http.Cookie objects
>> - Pass those to the app if/when requested
>>
>> In terms of handling RFC6265 and RFC2109 my plan is to have two parsers,
>> share as much code as possible and switch between them based on the
>> cookie header with the expectation that 99.9% of cookies will be parsed
>> by the RFC6265 parser. We could add some options to this switching to
>> enable other parsers (e.g. a Netscape parser) to be used.
>>
>> I'd also like to keep the current cookie parsing implementation for now.
>> Until we are happy with the new parsing, the current implementation will
>> be the default. Once we are happy with the new parsing we can change the
>> default. We can add an option to switch between the current and the new
>> parsing.
>>
>> Thoughts?
>>
> 
> As far as I am concerned, this could turn out badly.

I agree. I remember the last time I made changes to the cookie parsing
to improve spec compliance as a result of some security issues. It broke
a lot of stuff and the fall out lasted for months. I don't want to
repeat that.

> String manipulation is
> consistently the slowest thing overall other than IO, and rather often
> webapps use a massive amount of cookies [to the point they get errors
> because the HTTP header size is too small by default].

I agree the new code is going to have to keep a careful eye on performance.

> So the current processing should probably be the default [as proposed],
> then remain an option until it can be demonstrated this is not slower
> [which IMO is not possible, so it would have to remain].

The problem is that the current approach simply can't work for UTF-8
cookie values. I intend to start with some performance tests so we can
see what the difference really is. I'm expecting that we will need to
trade a little performance to be able to handle UTF-8. Whether or not
that trade is a reasonable one will depend on the performance figures. I
suggest we hold off on that debate until we have some hard numbers to
work with.

Mark

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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Mark Thomas
On 26/08/2014 22:52, Filip Hanik wrote:
> On Tue, Aug 26, 2014 at 12:53 PM, Mark Thomas  wrote:
> 
>> One of the aims of the proposed cookie changes [1] was to deal with the
>> HTML 5 changes that mean UTF-8 can appear in cookie headers.
>>
>> This has some potentially large implications for Tomcat.
>>
> 
> ​Since we already are in the 8.0.x release cycle, I, as an end user/system
> administrator, would expect parsing would remain 100% backwards compatible
> for version 8.0.x+n (n=1...)​

+1

>> Currently, Tomcat handles cookies as MessageBytes, processing everything
>> in bytes and only converting to String when necessary. This is largely
>> possible because of the assumption that everything is ASCII.
>>
>> Introduce UTF-8 and processing everything in bytes gets a whole lot
>> harder. You essentially have to decode to UTF-8 to ensure that you have
>> valid data - at a which point why not just use Strings anyway?
>>
>> I am currently leaning towards removing a lot of the current cookie
>> header caching  recycling and doing something along the following lines:
>>
> 
> ​all that caching/recycling is to avoid GC cycles and was in the past a
> crucial performance optimization.
> ​back in those days, with the hardware that was available in 06-07, we were
> pushing a single Tomcat instance to 60k requests per second.
> creating new objects was painfully expensive at that rate.

I've done some work on reducing GC when Tomcat was being hammered with
large numbers of requests fairly recently so I agree this is an issue we
still need to keep an eye on.

>> - Lazy parsing as currently (but unless cookie based session tracking is
>>   disabled this is going to run on every request)
>>
> 
> ​but our cookies, JSESSIONID, doesn't have to be UTF-8, does it?
> this goes hand in hand with the SessionIdGenerator that Rainer just did,
> can that return UTF-8 values?
> So the lazy part can apply to all other cookies, meaning, don't parse it
> until the app requests it, just store the bytes and move on.

Good news: I don't believe the session IDs are UTF-8.

Bad news: The issue is that if there is a chance of UTF-8 in the header
then you can't simply split the header into individual cookies based on
the separator byte since you can't tell (without decoding to characters)
if a byte represents the separator or is part of a sequence of several
bytes representing some other character.

Aside: I think putting UTF-8 into HTTP headers is a crazy idea but that
ship has sailed and we have to deal with it.

>> - Convert headers to UTF-8 strings
>> 
>> - Parse them with a new parser along the lines of o.a.t.u.http.parser
>> - Have that parser return an array of javax.servlet.http.Cookie objects
>> - Pass those to the app if/when requested
>>
>> In terms of handling RFC6265 and RFC2109 my plan is to have two parsers,
>> share as much code as possible and switch between them based on the
>> cookie header with the expectation that 99.9% of cookies will be parsed
>> by the RFC6265 parser. We could add some options to this switching to
>> enable other parsers (e.g. a Netscape parser) to be used.
>>
> 
> ​I like the idea of swappable parsers, with the default is the exact
> behavior you see now. I can see changing the default after some
> stabilization.​

Same here.


>> I'd also like to keep the current cookie parsing implementation for now.
>> Until we are happy with the new parsing, the current implementation will
>> be the default. Once we are happy with the new parsing we can change the
>> default. We can add an option to switch between the current and the new
>> parsing.
>>
>> Thoughts?
>>
> 
> ​knock it out.

That is the plan :)

Mark


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



Re: svn commit: r1620596 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/servlet/ test/org/apache/jasper/servlet/ test/webapp/jsp/ webapps/docs/

2014-08-27 Thread Rémy Maucherat
2014-08-27 11:06 GMT+02:00 Mark Thomas :

> I've started to ignore the CI failures due to the false positive rate.
> That is probably a sign some time needs to be spent looking at the CI
> failures and fixing them.
>
> I'm not a fan of gump and am mostly looking at CI instead for testsuite
runs. However, there are no false positives at all there right now since
the poor thing seems dead. Problem solved !
http://ci.apache.org/builders/tomcat-trunk

Rémy


svn commit: r1620827 - in /tomcat/tc7.0.x/trunk: ./ test/org/apache/tomcat/util/net/TestCustomSsl.java

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 09:15:18 2014
New Revision: 1620827

URL: http://svn.apache.org/r1620827
Log:
Update expected value after changes in r1617447

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/net/TestCustomSsl.java

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1617469

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/net/TestCustomSsl.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/net/TestCustomSsl.java?rev=1620827&r1=1620826&r2=1620827&view=diff
==
--- tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/net/TestCustomSsl.java 
(original)
+++ tomcat/tc7.0.x/trunk/test/org/apache/tomcat/util/net/TestCustomSsl.java Wed 
Aug 27 09:15:18 2014
@@ -146,7 +146,7 @@ public class TestCustomSsl extends Tomca
 }
 if (serverTrustAll) {
 assertEquals(200, rc);
-assertEquals("OK", res.toString());
+assertEquals("OK-" + TesterSupport.ROLE, res.toString());
 } else {
 assertTrue(rc != 200);
 assertEquals("", res.toString());



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



Re: svn commit: r1620596 - in /tomcat/trunk: java/org/apache/jasper/compiler/ java/org/apache/jasper/servlet/ test/org/apache/jasper/servlet/ test/webapp/jsp/ webapps/docs/

2014-08-27 Thread Mark Thomas
On 26/08/2014 23:16, Konstantin Kolinko wrote:
> 2014-08-26 17:32 GMT+04:00  :
>> Author: markt
>> Date: Tue Aug 26 13:32:45 2014
>> New Revision: 1620596
>>
>> URL: http://svn.apache.org/r1620596
>> Log:
>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56568
>> Enable any HTTP method to be used to request a JSP page that has the 
>> isErrorPage page directive set to true.
>>
>> Added:
>> tomcat/trunk/test/webapp/jsp/error.jsp   (with props)
>> Modified:
>> tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
>> tomcat/trunk/java/org/apache/jasper/servlet/JspServlet.java
>> tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
>> tomcat/trunk/test/org/apache/jasper/servlet/TestJspServlet.java
>> tomcat/trunk/webapps/docs/changelog.xml
>> Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1620596&r1=1620595&r2=1620596&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
>> +++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Tue Aug 26 
>> 13:32:45 2014
>> @@ -255,6 +255,11 @@ public abstract class Compiler {
>>  // to be GC'd and save memory.
>>  ctxt.setWriter(null);
>>
>> +// Need to know if the JSP is an error page at runtime to 
>> determine
>> +// which HTTP methods are permitted. Error pages permit any. 
>> Normal
>> +// pages only permit GET, POST or HEAD.
>> +jsw.setErrorPage(pageInfo.isErrorPage());
>> +
> 
> Apparently this causes org.apache.jasper.TestJspC to fail with many NPEs,
> as noted by  Gump in tomcat-trunk-test-nio:
> 
> [junit] java.lang.NullPointerException
> [junit] at 
> org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:261)
> [junit] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361)
> [junit] at org.apache.jasper.JspC.processFile(JspC.java:1217)
> 
> All other test cases completed successfully.

Thanks. Fixed.

I've started to ignore the CI failures due to the false positive rate.
That is probably a sign some time needs to be spent looking at the CI
failures and fixing them.

Mark


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



svn commit: r1620822 - /tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 09:05:21 2014
New Revision: 1620822

URL: http://svn.apache.org/r1620822
Log:
Avoid NPE when using JspC

Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java

Modified: tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java?rev=1620822&r1=1620821&r2=1620822&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Compiler.java Wed Aug 27 
09:05:21 2014
@@ -255,10 +255,12 @@ public abstract class Compiler {
 // to be GC'd and save memory.
 ctxt.setWriter(null);
 
-// Need to know if the JSP is an error page at runtime to determine
-// which HTTP methods are permitted. Error pages permit any. Normal
-// pages only permit GET, POST or HEAD.
-jsw.setErrorPage(pageInfo.isErrorPage());
+if (jsw != null) {
+// Need to know if the JSP is an error page at runtime to 
determine
+// which HTTP methods are permitted. Error pages permit any. 
Normal
+// pages only permit GET, POST or HEAD.
+jsw.setErrorPage(pageInfo.isErrorPage());
+}
 
 if (log.isDebugEnabled()) {
 t4 = System.currentTimeMillis();



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



Re: Coverity static analysis scanning

2014-08-27 Thread Mark Thomas
On 26/08/2014 22:26, Christopher Schultz wrote:
> Mark,
> 
> On 8/26/14, 5:20 AM, Mark Thomas wrote:
>> I have been pinged off-list by Coverity to say that they have set up
>> Tomcat with a free account with their static code analysis service.
>>
>> I think I have the ability to send invitations so if anyone wants to
>> take a look at the results, just reply here.
>>
>> I have taken a quick look and they do appear to have found some valid
>> threading issues. There are ~350 issues in total and I don't yet have a
>> feel for the false positive rate.
> 
> Wow, this is great. I've used FindBugs before both inside and outside of
> ASF projects, but this is ... just amazing.

It certainly appears to be an improvement on what was on offer the last
time we were approach by one of the static code analysis firms.
Personally, I'm withholding judgement until I get a better feel for what
% of the issues raises are ones that are likely to cause problems for
our users.

> It does catch a lot of sanity-checks and complains about them. I get
> DEAD CODE warnings all the time (in FindBugs) for especially JDBC code
> when I've caught all possible exceptions and yet still have a finally
> block that, for example, checks a Connection reference for null and
> closes it in that case. While the code is technically dead, it's
> future-proof against someone adding another call that throws a different
> type of exception, re-ordering some of the operations, or making some
> other change and forgetting to modify the finally block, etc.
> 
> It would be nice to know what the consensus is amongst the team about
> what to do in these cases: should all dead code segments be considered
> logical oversights and corrected? Or is additional sanity-checking and
> future-proofing a good idea?

It depends :)

I think there are some cases where I'd agree it is a good idea and some
where I'd think it was a waste of time and code.

> A good example is issue 45040
> (https://scan3.coverity.com:8443/reports.htm#v16818/p10363/fileInstanceId=567725&defectInstanceId=145101&mergedDefectId=45040):
> a logical bug in HttpServlet that should probably remain as-is. It's in
> the HttpServlet.doOptions method where we build a list of acceptable
> HTTP verbs. /Technically/, if ALLOW_GET is set, then ALLOW_HEAD must be
> set and therefore checking for "allow" (the string of verbs we're
> building) for NULL is illogical. One could argue that ALLOW_HEAD should
> be independent of ALLOW_GET -- why can't a servlet implement doHead but
> not doGet -- but it probably always makes sense to check for null.
> Stated differently: checking for NULL never hurt anybody.

I disagree. In this case if the servlet extends HttpServlet and
implements doGet(), HttpServlet provides the doHead() implementation.
I'd clean that code up and remove the dead code. That said, if have
other things higher up my priority list right now.

Mark


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



svn commit: r1620815 - /tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 08:44:41 2014
New Revision: 1620815

URL: http://svn.apache.org/r1620815
Log:
Simplify

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

Modified: tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java?rev=1620815&r1=1620814&r2=1620815&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java Wed 
Aug 27 08:44:41 2014
@@ -60,7 +60,7 @@ public class CatalinaProperties {
 Throwable error = null;
 
 try {
-String configUrl = getConfigUrl();
+String configUrl = System.getProperty("catalina.config");
 if (configUrl != null) {
 is = (new URL(configUrl)).openStream();
 }
@@ -123,14 +123,6 @@ public class CatalinaProperties {
 }
 
 
-/**
- * Get the value of the configuration URL.
- */
-private static String getConfigUrl() {
-return System.getProperty("catalina.config");
-}
-
-
 // Copied from ExceptionUtils since that class is not visible during start
 private static void handleThrowable(Throwable t) {
 if (t instanceof ThreadDeath) {



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



svn commit: r1620814 - /tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java

2014-08-27 Thread markt
Author: markt
Date: Wed Aug 27 08:42:58 2014
New Revision: 1620814

URL: http://svn.apache.org/r1620814
Log:
Clean-up

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

Modified: tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java?rev=1620814&r1=1620813&r2=1620814&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/CatalinaProperties.java Wed 
Aug 27 08:42:58 2014
@@ -95,9 +95,7 @@ public class CatalinaProperties {
 } catch (Throwable t) {
 handleThrowable(t);
 error = t;
-}
-finally
-{
+} finally {
 try {
 is.close();
 } catch (IOException ioe) {
@@ -110,7 +108,7 @@ public class CatalinaProperties {
 // Do something
 log.warn("Failed to load catalina.properties", error);
 // That's fine - we have reasonable defaults.
-properties=new Properties();
+properties = new Properties();
 }
 
 // Register the properties as system properties



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



Re: RFC6265, cookie parsing and UTF-8

2014-08-27 Thread Rainer Jung

Am 26.08.2014 um 23:52 schrieb Filip Hanik:


​but our cookies, JSESSIONID, doesn't have to be UTF-8, does it?
this goes hand in hand with the SessionIdGenerator that Rainer just did,
can that return UTF-8 values?


We currently only bundle one impl of that and that impl hasn't changed, 
so it still uses random bytes encoded in hex digits.


But: as we know it appends the jvmRoute if set. That a user could try to 
set as UTF-8. But I guess it is extremely unlikely due to the jvmRoute 
often also being used in other legacy config files which don't support 
UTF-8.


A custom implementation of SessionIdGenerator currently would be free to 
return any string it likes. We can still change the API or docs though, 
it hasn't yet had any release.


I personally would find it bad practise to generate session IDs with 
non-ascii characters or even characters from the reserved set because 
the correct handling of that in all cases (cookie, uri encoded; load 
balancers, proxies etc.) would be unnecessarily fragile. Should I add 
something along those lines to the SessionIdGenerator docs?


Regards,

Rainer



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