[Bug 60451] java.lang.ArrayIndexOutOfBoundsException when a servlet writes more than the output buffer max length on a connection to be upgraded to HTTP/2

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60451

--- Comment #1 from Ludovic Pénet  ---
Well, my first analysis of this problem was wrong.

After further debugging, it appears that the problem is rather in the
"Content-Disposition" header value.

As we are in France, it sometimes contains non ascii chars. In this case, char
é caused the exception in HPackHuffman.encode.

So, I changed the way I set the header from :

resp.setHeader("Content-Disposition", "attachment;filename=\"" +
filename + "\"");

to :

URLEncoder enc = new URLEncoder();
resp.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" +
enc.encode(filename, "UTF-8"));

and it works.

-- 
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: Same request object passed to two threads

[Violeta Georgieva]

Hi,

2016-12-08 3:48 GMT+02:00 Matthew Bellew :
>
> I have narrowed this down quite a lot.  This bug is caused by the same
> Http11Processor being pushed on to the recycledProcessors stack twice.  I
> discovered this by add a duplicates check in recycledProcessors.push()
>
> @SuppressWarnings("sync-override") // Size may exceed cache size a bit
> public boolean push(Processor processor, String source) {
> int cacheSize = handler.getProtocol().getProcessorCache();
> boolean offer = cacheSize == -1 ? true : size.get() < cacheSize;
> //avoid over growing our cache or add after we have stopped
> boolean result = false;
> if (offer) {
> +synchronized (this)
> +{
> +for (int i=0 ; i<=index ; i++)
> +assert processor != stack[i];
> result = super.push(processor);
> +}
> if (result) {
> size.incrementAndGet();
> }
> }
> if (!result) handler.unregister(processor);
> return result;
> }
>
>
> A bit more hacking showed that the processor would be pushed first via
> ConnectionHandler.release(*SocketWrapperBase*) called from
> Pooler.cancelledKey() (NOTE: AbstractProtocolJava line numbers don't line
> up with 8.5.8 because of debug code)
>
> at
>
org.apache.coyote.AbstractProtocol$RecycledProcessors.push(AbstractProtocol.java:1116)
> at
>
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1002)
> at
>
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1016)
> at
>
org.apache.tomcat.util.net.NioEndpoint$Poller.cancelledKey(NioEndpoint.java:730)
> at
>
org.apache.tomcat.util.net.NioEndpoint$Poller.processSendfile(NioEndpoint.java:966)
> at
>
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.processSendfile(NioEndpoint.java:1305)
> at
>
org.apache.coyote.http11.Http11Processor.breakKeepAliveLoop(Http11Processor.java:1611)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:852)
> at
>
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
>
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
> at
>
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
> at
>
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
>
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> The second push of the same processor happens via the "normal"
> ConnectionHandler.release(*Processor*) called from
> ConnectionHandler.process()
>
> at
>
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1002)
> at
>
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:927)
> at
>
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
> at
>
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> - locked <0x62c2> (a
> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
> at
>
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
>
> I don't know understand the whole processSendFile() and state=SENDFILE
> logic.  One suspicious thing comparing the two stack traces is that
> ConnectionHandler.process() does not check the return result from
> connections.remove().  Maybe

May be you are facing the issue reported here [1]

Can you test with 8.5.9 that we vote currently [2]?

Regards,
Violeta

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60409
[2] http://marc.info/?l=tomcat-dev=148097070419476=2

> a) ConnectionHandler.process() should only call release(processor) if the
> connections.remove(socket)==processor?
> or
> b) release(socket) shouldn't call recycledProcessors.push()?
>
> Matt
>
>
> On Tue, Dec 6, 2016 at 3:53 PM, Matthew Bellew 
wrote:
>
> > Thanks for the pointer to org.apache.catalina.connector.RECYCLE_FACADES.
> > I will try running our integration server with that set both ways and
> > compare.
> >
> > I don't see how an application bug could cause the same RequestFacade to
> > be passed to the webapp on two thread concurrently, however.  I'm not
> > guessing about that.  I added debugging code to my app and managed to
stop
> > in the debugger, and I could see two http-nio-8080-exec- threads with
the
> > same object.
> >
> > Matt
> >
> > On Tue, Dec 6, 2016 at 2:58 PM, Caldarale, Charles R <
> > chuck.caldar...@unisys.com> wrote:
> >
> >> From: Matthew 

svn commit: r1773156 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AbstractEndpoint.java Nio2Endpoint.java NioEndpoint.java

[markt]

Author: markt
Date: Wed Dec  7 22:06:31 2016
New Revision: 1773156

URL: http://svn.apache.org/viewvc?rev=1773156=rev
Log:
Remove more unused code.

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

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1773156=1773155=1773156=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Wed Dec  
7 22:06:31 2016
@@ -154,7 +154,7 @@ public abstract class AbstractEndpointhttp://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java?rev=1773156=1773155=1773156=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Dec  7 
22:06:31 2016
@@ -100,10 +100,6 @@ public class Nio2Endpoint extends Abstra
 
 // - Properties
 
-public void setSocketProperties(SocketProperties socketProperties) {
-this.socketProperties = socketProperties;
-}
-
 /**
  * Is deferAccept supported?
  */

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1773156=1773155=1773156=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Wed Dec  7 
22:06:31 2016
@@ -162,10 +162,6 @@ public class NioEndpoint extends Abstrac
 this.selectorPool = selectorPool;
 }
 
-public void setSocketProperties(SocketProperties socketProperties) {
-this.socketProperties = socketProperties;
-}
-
 /**
  * Is deferAccept supported?
  */



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

svn commit: r1773154 - in /tomcat/trunk/java/org/apache/tomcat/util/net: Nio2Endpoint.java NioEndpoint.java

[markt]

Author: markt
Date: Wed Dec  7 21:55:34 2016
New Revision: 1773154

URL: http://svn.apache.org/viewvc?rev=1773154=rev
Log:
Remove unused methods

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.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=1773154=1773153=1773154=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Dec  7 
21:55:34 2016
@@ -277,15 +277,6 @@ public class Nio2Endpoint extends Abstra
 
 // -- Protected Methods
 
-
-public int getWriteBufSize() {
-return socketProperties.getTxBufSize();
-}
-
-public int getReadBufSize() {
-return socketProperties.getRxBufSize();
-}
-
 @Override
 protected Acceptor createAcceptor() {
 return new Acceptor<>(this);

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1773154=1773153=1773154=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Wed Dec  7 
21:55:34 2016
@@ -325,15 +325,6 @@ public class NioEndpoint extends Abstrac
 
 // -- Protected Methods
 
-
-public int getWriteBufSize() {
-return socketProperties.getTxBufSize();
-}
-
-public int getReadBufSize() {
-return socketProperties.getRxBufSize();
-}
-
 public NioSelectorPool getSelectorPool() {
 return selectorPool;
 }



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

svn commit: r1773155 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AbstractEndpoint.java AprEndpoint.java Nio2Endpoint.java NioEndpoint.java

[markt]

Author: markt
Date: Wed Dec  7 21:58:38 2016
New Revision: 1773155

URL: http://svn.apache.org/viewvc?rev=1773155=rev
Log:
Simplify Acceptor creation.

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

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1773155=1773154=1773155=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Wed Dec  
7 21:58:38 2016
@@ -932,12 +932,13 @@ public abstract class AbstractEndpoint(count);
 
 for (int i = 0; i < count; i++) {
-Acceptor acceptor = createAcceptor();
+Acceptor acceptor = new Acceptor<>(this);
 String threadName = getName() + "-Acceptor-" + i;
 acceptor.setThreadName(threadName);
 acceptors.add(acceptor);
@@ -950,13 +951,6 @@ public abstract class AbstractEndpoint createAcceptor();
-
-
-/**
  * Pause the endpoint, which will stop it accepting new connections.
  */
 public void pause() {

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1773155=1773154=1773155=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed Dec  7 
21:58:38 2016
@@ -722,12 +722,6 @@ public class AprEndpoint extends Abstrac
 
 // -- Protected Methods
 
-@Override
-protected Acceptor createAcceptor() {
-return new Acceptor<>(this);
-}
-
-
 /**
  * Process the specified connection.
  * @param socketWrapper The socket wrapper

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=1773155=1773154=1773155=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Wed Dec  7 
21:58:38 2016
@@ -277,11 +277,6 @@ public class Nio2Endpoint extends Abstra
 
 // -- Protected Methods
 
-@Override
-protected Acceptor createAcceptor() {
-return new Acceptor<>(this);
-}
-
 /**
  * Process the specified connection.
  * @param socket The socket channel

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1773155=1773154=1773155=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Wed Dec  7 
21:58:38 2016
@@ -330,12 +330,6 @@ public class NioEndpoint extends Abstrac
 }
 
 
-@Override
-protected Acceptor createAcceptor() {
-return new Acceptor<>(this);
-}
-
-
 /**
  * Process the specified connection.
  * @param socket The socket channel



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

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/1952

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1773037
Blamelist: markt

Build succeeded!

Sincerely,
 -The Buildbot




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

Re: svn commit: r1773036 - in /tomcat/trunk: java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ java/org/apache/tomcat/websocket/server

[Mark Thomas]

On 07/12/2016 09:28, ma...@apache.org wrote:
> Author: markt
> Date: Wed Dec  7 09:28:40 2016
> New Revision: 1773036
> 
> URL: http://svn.apache.org/viewvc?rev=1773036=rev
> Log:
> Refactor the per Endpoint Acceptors into a single Acceptor class.

Some additional commentary:

- The I/O refactoring still feels like a work in progress. My aim
  remains reducing duplication and edge case differences between the
  three Endpoint implementations.

- Endpoint does reach quite a long way up the I/O stack. That doesn't
  seem quite right but I haven't looked at it closely.

- I ran the unit tests and they all passed after these changes.

- I'm on the fence whether to back-port this to 8.5.x. or not.

Mark

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

buildbot failure in on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/1951

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1773036
Blamelist: markt

BUILD FAILED: failed compile

Sincerely,
 -The Buildbot




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

svn commit: r1773037 - /tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java

[markt]

Author: markt
Date: Wed Dec  7 09:38:59 2016
New Revision: 1773037

URL: http://svn.apache.org/viewvc?rev=1773037=rev
Log:
Fix Javadoc

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

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1773037=1773036=1773037=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Wed Dec  
7 09:38:59 2016
@@ -46,9 +46,9 @@ import org.apache.tomcat.util.threads.Th
 
 /**
  * @param  The type used by the socket wrapper associated with this 
endpoint.
- *May be the same as .
+ *May be the same as U.
  * @param  The type of the underlying socket used by this endpoint. May be
- *the same as .
+ *the same as S.
  *
  * @author Mladen Turk
  * @author Remy Maucherat



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

svn commit: r1773036 - in /tomcat/trunk: java/org/apache/coyote/ java/org/apache/coyote/ajp/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ java/org/apache/tomcat/websocket/server/ we

[markt]

Author: markt
Date: Wed Dec  7 09:28:40 2016
New Revision: 1773036

URL: http://svn.apache.org/viewvc?rev=1773036=rev
Log:
Refactor the per Endpoint Acceptors into a single Acceptor class.

Added:
tomcat/trunk/java/org/apache/tomcat/util/net/Acceptor.java   (with props)
Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
tomcat/trunk/java/org/apache/coyote/ajp/AbstractAjpProtocol.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11JsseProtocol.java
tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Protocol.java
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapperBase.java

tomcat/trunk/java/org/apache/tomcat/websocket/server/WsRemoteEndpointImplServer.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java?rev=1773036=1773035=1773036=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java Wed Dec  7 
09:28:40 2016
@@ -46,7 +46,7 @@ public abstract class AbstractProcessor
 protected Adapter adapter;
 protected final AsyncStateMachine asyncStateMachine;
 private volatile long asyncTimeout = -1;
-protected final AbstractEndpoint endpoint;
+protected final AbstractEndpoint endpoint;
 protected final Request request;
 protected final Response response;
 protected volatile SocketWrapperBase socketWrapper = null;
@@ -59,12 +59,12 @@ public abstract class AbstractProcessor
 private ErrorState errorState = ErrorState.NONE;
 
 
-public AbstractProcessor(AbstractEndpoint endpoint) {
+public AbstractProcessor(AbstractEndpoint endpoint) {
 this(endpoint, new Request(), new Response());
 }
 
 
-protected AbstractProcessor(AbstractEndpoint endpoint, Request 
coyoteRequest,
+protected AbstractProcessor(AbstractEndpoint endpoint, Request 
coyoteRequest,
 Response coyoteResponse) {
 this.endpoint = endpoint;
 asyncStateMachine = new AsyncStateMachine(this);

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java?rev=1773036=1773035=1773036=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java Wed Dec  7 
09:28:40 2016
@@ -87,7 +87,7 @@ public abstract class AbstractProtocol endpoint;
+private final AbstractEndpoint endpoint;
 
 
 private Handler handler;
@@ -103,7 +103,7 @@ public abstract class AbstractProtocol endpoint) {
+public AbstractProtocol(AbstractEndpoint endpoint) {
 this.endpoint = endpoint;
 setConnectionLinger(Constants.DEFAULT_CONNECTION_LINGER);
 setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
@@ -364,7 +364,7 @@ public abstract class AbstractProtocol getEndpoint() {
+protected AbstractEndpoint getEndpoint() {
 return endpoint;
 }
 

Modified: tomcat/trunk/java/org/apache/coyote/ajp/AbstractAjpProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AbstractAjpProtocol.java?rev=1773036=1773035=1773036=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AbstractAjpProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AbstractAjpProtocol.java Wed Dec  7 
09:28:40 2016
@@ -41,7 +41,7 @@ public abstract class AbstractAjpProtoco
 protected static final StringManager sm = 
StringManager.getManager(AbstractAjpProtocol.class);
 
 
-public AbstractAjpProtocol(AbstractEndpoint endpoint) {
+public AbstractAjpProtocol(AbstractEndpoint endpoint) {
 super(endpoint);
 setConnectionTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
 // AJP does not use Send File
@@ -64,7 +64,7 @@ public abstract class AbstractAjpProtoco
  * Overridden to make getter accessible to other classes in this package.
  */
 @Override
-protected AbstractEndpoint getEndpoint() {
+protected AbstractEndpoint getEndpoint() {
 return 

[Bug 60450] Setting keystore type shouldn't override the truststore type

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60450

--- Comment #2 from Axel Fontaine  ---
Or couldn't this whole setting simply default to autodetection? After all we
can now simply set it to  JKS and this will autodetect both PKCS12 and JKS (see
https://bugs.openjdk.java.net/browse/JDK-8062552)

Therefore I believe a default of JKS should be a fine one, instead of the
current behavior where setting the keystore type to PKCS12 without overriding
the default truststore type almost invariably results in a cryptic and hard to
debug failure.

-- 
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 60450] New: Setting keystore type shouldn't override the truststore type

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60450

Bug ID: 60450
   Summary: Setting keystore type shouldn't override the
truststore type
   Product: Tomcat 8
   Version: 8.5.x-trunk
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Util
  Assignee: dev@tomcat.apache.org
  Reporter: a...@boxfuse.com
  Target Milestone: 

Say I have a keystore in PKCS12 format and a truststore in the default JKS
format.

By setting the keystore type (PKCS12) and NOT explicitly overriding the default
truststore type (JKS), the truststore type now also gets changed to PKCS12 and
fails to load.

This line is the issue:
https://github.com/apache/tomcat/blob/trunk/java/org/apache/tomcat/util/net/SSLHostConfig.java#L585

This behavior is currently very unintuitive and not documented anywhere. I
strongly believe change the keystore type should not secretly alter the
truststore type.

-- 
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 60450] Setting keystore type shouldn't override the truststore type

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60450

Mark Thomas  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Mark Thomas  ---
>From the 8.5.x documentation:


truststoreType  
JSSE only.

The type of key store used for the trust store. The default is the value of the
javax.net.ssl.trustStoreType system property. If that property is null, the
value of keystoreType is used as the default.


Those docs could do with an update to make clear it is the key store type of
the default certificate that is used.

PKCS12 is somewhat of a special case since the trust store is unlikely to be in
the same format as the key store.

I'm currently leaning towards WONTFIX for the original request in this report
since the behaviour is documented and makes sense for key store types other
than PKCS12.

A possible enhancement could be for the trust store type to default to JKS if
the keys store type is PKCS12. However, that would add complexity.

-- 
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: r1773093 - /tomcat/trunk/java/org/apache/catalina/connector/Request.java

[markt]

Author: markt
Date: Wed Dec  7 15:08:50 2016
New Revision: 1773093

URL: http://svn.apache.org/viewvc?rev=1773093=rev
Log:
Remove deprecated code

Modified:
tomcat/trunk/java/org/apache/catalina/connector/Request.java

Modified: tomcat/trunk/java/org/apache/catalina/connector/Request.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Request.java?rev=1773093=1773092=1773093=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Request.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Request.java Wed Dec  7 
15:08:50 2016
@@ -577,18 +577,6 @@ public class Request implements HttpServ
 return mappingData.context;
 }
 
-/**
- * @param context The newly associated Context
- * @deprecated Use setters on {@link #getMappingData() MappingData} object.
- * Depending on use case, you may need to update other
- * MappingData fields as well, such as
- * contextSlashCount and host.
- */
-@Deprecated
-public void setContext(Context context) {
-mappingData.context = context;
-}
-
 
 /**
  * Filter chain associated with the request.
@@ -738,22 +726,9 @@ public class Request implements HttpServ
 return mappingData.wrapper;
 }
 
-/**
- * @param wrapper The newly associated Wrapper
- * @deprecated Use setters on {@link #getMappingData() MappingData} object.
- * Depending on use case, you may need to update other
- * MappingData fields as well, such as context
- * and contextSlashCount.
- */
-@Deprecated
-public void setWrapper(Wrapper wrapper) {
-mappingData.wrapper = wrapper;
-}
-
 
 // - Request Public Methods
 
-
 /**
  * Create and return a ServletInputStream to read the content
  * associated with this Request.



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

Missing commit for CVE-2016-6797 on the security pages

[Emmanuel Bourg]

Hi,

The security pages are missing another commit, this time for
CVE-2016-6797. The newly added validateGlobalResourceAccess method in
ResourceLinkFactory was later modified to iterate over the classloader
hierarchy. Without this modification some applications are no longer
able to access their datasource (this happened to Debian users [1]
installing the latest security update).

Here are the commits per version if someone could update the pages:

Tomcat 6:   https://svn.apache.org/r1763237
Tomcat 7:   https://svn.apache.org/r1763236
Tomcat 8:   https://svn.apache.org/r1763234
Tomcat 8.5: https://svn.apache.org/r1763233
Tomcat 9:   https://svn.apache.org/r1763232

Thank you,

Emmanuel Bourg

[1] https://bugs.debian.org/845425

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

[Bug 60451] New: java.lang.ArrayIndexOutOfBoundsException when a servlet writes more than the output buffer max length on a connection to be upgraded to HTTP/2

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60451

Bug ID: 60451
   Summary: java.lang.ArrayIndexOutOfBoundsException when a
servlet writes more than the output buffer max length
on a connection to be upgraded to HTTP/2
   Product: Tomcat 8
   Version: 8.5.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: regression
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: l.pe...@senat.fr
  Target Milestone: 

I have a simple servlet producing files in Excel format using Apache POI.

It basically does a 

wbk.write(resp.getOutputStream());

where wbk is an instance of org.apache.poi.ss.usermodel.Workbook and resp is an
instance of HttpServletResponse.

When my SSL connector is parametered this way


  


in server.xml, I have the following exception.

07-Dec-2016 16:24:58.603 GRAVE [https-openssl-apr-8443-exec-19]
org.apache.catalina.core.StandardWrapperValve.invoke "Servlet.service()" pour
la servlet fr.senat.presences.servlets.ExcelPresencesServlet a généré une
exception
 java.lang.ArrayIndexOutOfBoundsException: -23
at org.apache.coyote.http2.HPackHuffman.encode(HPackHuffman.java:441)
at
org.apache.coyote.http2.HpackEncoder.writeHuffmanEncodableValue(HpackEncoder.java:228)
at org.apache.coyote.http2.HpackEncoder.encode(HpackEncoder.java:190)
at
org.apache.coyote.http2.Http2UpgradeHandler.writeHeaders(Http2UpgradeHandler.java:534)
at org.apache.coyote.http2.Stream.writeHeaders(Stream.java:326)
at
org.apache.coyote.http2.StreamProcessor.prepareResponse(StreamProcessor.java:98)
at
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:263)
at org.apache.coyote.Response.action(Response.java:170)
at org.apache.coyote.Response.sendHeaders(Response.java:352)
at
org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:582)
at org.apache.coyote.Response.doWrite(Response.java:517)
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:351)
at
org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:808)
at
org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:713)
at
org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:391)
at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:369)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)
at
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
at org.apache.poi.poifs.storage.BigBlock.doWriteData(BigBlock.java:67)
at
org.apache.poi.poifs.storage.DocumentBlock.writeData(DocumentBlock.java:195)
at org.apache.poi.poifs.storage.BigBlock.writeBlocks(BigBlock.java:98)
at
org.apache.poi.poifs.storage.DocumentBlock.writeBlocks(DocumentBlock.java:34)
at
org.apache.poi.poifs.filesystem.POIFSDocument$BigBlockStore.writeBlocks(POIFSDocument.java:547)
at
org.apache.poi.poifs.filesystem.POIFSDocument.writeBlocks(POIFSDocument.java:303)
at
org.apache.poi.poifs.filesystem.POIFSFileSystem.writeFilesystem(POIFSFileSystem.java:380)
at
org.apache.poi.hssf.usermodel.HSSFWorkbook.write(HSSFWorkbook.java:1308)
at
fr.senat.exporters.ExcelExporter.exportActivite(ExcelExporter.java:578)
at
fr.senat.presences.servlets.ExcelPresencesServlet.doGetActivite(ExcelPresencesServlet.java:89)
at
fr.senat.presences.servlets.ExcelPresencesServlet.doGet(ExcelPresencesServlet.java:39)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
fr.senat.presences.filters.PseudoRequestScopeEMFilter.doFilter(PseudoRequestScopeEMFilter.java:95)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at

Re: Same request object passed to two threads

[Matthew Bellew]

I have narrowed this down quite a lot.  This bug is caused by the same
Http11Processor being pushed on to the recycledProcessors stack twice.  I
discovered this by add a duplicates check in recycledProcessors.push()

@SuppressWarnings("sync-override") // Size may exceed cache size a bit
public boolean push(Processor processor, String source) {
int cacheSize = handler.getProtocol().getProcessorCache();
boolean offer = cacheSize == -1 ? true : size.get() < cacheSize;
//avoid over growing our cache or add after we have stopped
boolean result = false;
if (offer) {
+synchronized (this)
+{
+for (int i=0 ; i<=index ; i++)
+assert processor != stack[i];
result = super.push(processor);
+}
if (result) {
size.incrementAndGet();
}
}
if (!result) handler.unregister(processor);
return result;
}


A bit more hacking showed that the processor would be pushed first via
ConnectionHandler.release(*SocketWrapperBase*) called from
Pooler.cancelledKey() (NOTE: AbstractProtocolJava line numbers don't line
up with 8.5.8 because of debug code)

at
org.apache.coyote.AbstractProtocol$RecycledProcessors.push(AbstractProtocol.java:1116)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1002)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1016)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.cancelledKey(NioEndpoint.java:730)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.processSendfile(NioEndpoint.java:966)
at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.processSendfile(NioEndpoint.java:1305)
at
org.apache.coyote.http11.Http11Processor.breakKeepAliveLoop(Http11Processor.java:1611)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:852)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

The second push of the same processor happens via the "normal"
ConnectionHandler.release(*Processor*) called from
ConnectionHandler.process()

at
org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1002)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:927)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
- locked <0x62c2> (a
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)


I don't know understand the whole processSendFile() and state=SENDFILE
logic.  One suspicious thing comparing the two stack traces is that
ConnectionHandler.process() does not check the return result from
connections.remove().  Maybe

a) ConnectionHandler.process() should only call release(processor) if the
connections.remove(socket)==processor?
or
b) release(socket) shouldn't call recycledProcessors.push()?

Matt


On Tue, Dec 6, 2016 at 3:53 PM, Matthew Bellew  wrote:

> Thanks for the pointer to org.apache.catalina.connector.RECYCLE_FACADES.
> I will try running our integration server with that set both ways and
> compare.
>
> I don't see how an application bug could cause the same RequestFacade to
> be passed to the webapp on two thread concurrently, however.  I'm not
> guessing about that.  I added debugging code to my app and managed to stop
> in the debugger, and I could see two http-nio-8080-exec- threads with the
> same object.
>
> Matt
>
> On Tue, Dec 6, 2016 at 2:58 PM, Caldarale, Charles R <
> chuck.caldar...@unisys.com> wrote:
>
>> From: Matthew Bellew [mailto:matth...@labkey.com]
>> > Subject: Re: Same request object passed to two threads
>>
>> This should be on the users' mailing list, not dev.
>>
>> > Just realized that in the case above, I couldn't have hit the quoted
>> code,
>> > since neither call to AuthFilter.doFilter() had returned.
>>
>> > I can build and debug Tomcat, so any advice would be very welcome.
>>
>> Debug your webapp, not Tomcat.  In pretty much 100% of these cases, the
>> logic in a servlet or filter of the webapp is erroneously 

Re: [VOTE] Release Apache Tomcat 9.0.0.M15

[Huxing Zhang]

Hi,

The proposed 9.0.0.M15 release is:
[ ] Broken - do not release
[ X ] Alpha - go ahead and release as 9.0.0.M15

Test cases pass.
Our test web app works fine.

--
From:Mark Thomas 
Time:2016 Dec 5 (Mon) 22:47
To:dev@tomcat.apache.org 
Subject:[VOTE] Release Apache Tomcat 9.0.0.M15


The proposed Apache Tomcat 9.0.0.M15 release is now available for voting.

This is a milestone release for the 9.0.x branch. It should be
noted that, as a milestone release:
- Servlet 4.0 is not finalised
- The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0

The major changes compared to the 9.0.0.M13 release are:

- Improvements to SPNEGO authentication. Patches provided by Michael
  Osipov.

- Correct regression in I/O buffer handling.

- Improve handling of varargs in UEL expressions. Based on a patch by
  Ben.

Along with lots of other bug fixes and improvements

For full details, see the changelog:
http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M15/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1108/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M15/

The proposed 9.0.0.M15 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 9.0.0.M15

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

svn commit: r1773094 - /tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java

[markt]

Author: markt
Date: Wed Dec  7 15:10:24 2016
New Revision: 1773094

URL: http://svn.apache.org/viewvc?rev=1773094=rev
Log:
Remove dependency on MappingData from authenticator package
(Structure 101)

Modified:
tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java

Modified: 
tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java?rev=1773094=1773093=1773094=diff
==
--- tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/authenticator/AuthenticatorBase.java 
Wed Dec  7 15:10:24 2016
@@ -453,7 +453,7 @@ public abstract class AuthenticatorBase
 
 // The Servlet may specify security constraints through annotations.
 // Ensure that they have been processed before constraints are checked
-Wrapper wrapper = request.getMappingData().wrapper;
+Wrapper wrapper = request.getWrapper();
 if (wrapper != null) {
 wrapper.servletSecurityAnnotationScan();
 }



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

Re: [VOTE] Release Apache Tomcat 9.0.0.M15

[Felix Schumacher]

Am 5. Dezember 2016 15:47:41 MEZ, schrieb Mark Thomas :
>The proposed Apache Tomcat 9.0.0.M15 release is now available for
>voting.
>
>This is a milestone release for the 9.0.x branch. It should be
>noted that, as a milestone release:
>- Servlet 4.0 is not finalised
>- The EGs have not started work on JSP 2.4, EL 3.1 or WebSocket 1.2/2.0
>
>The major changes compared to the 9.0.0.M13 release are:
>
>- Improvements to SPNEGO authentication. Patches provided by Michael
>  Osipov.
>
>- Correct regression in I/O buffer handling.
>
>- Improve handling of varargs in UEL expressions. Based on a patch by
>  Ben.
>
>Along with lots of other bug fixes and improvements
>
>For full details, see the changelog:
>http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>
>It can be obtained from:
>https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.0.M15/
>The Maven staging repo is:
>https://repository.apache.org/content/repositories/orgapachetomcat-1108/
>The svn tag is:
>http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_9_0_0_M15/
>
>The proposed 9.0.0.M15 release is:
>[ ] Broken - do not release
>[x] Alpha - go ahead and release as 9.0.0.M15

Felix

>
>-
>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: [VOTE] Release Apache Tomcat 8.5.9

[Felix Schumacher]

Am 5. Dezember 2016 21:44:57 MEZ, schrieb Mark Thomas :
>The proposed Apache Tomcat 8.5.9 release is now available for voting.
>
>The major changes compared to the 8.5.8 release are:
>
>
>- Improvements to SPNEGO authentication. Patches provided by Michael
>  Osipov.
>
>- Correct regression in I/O buffer handling.
>
>- Improve handling of varargs in UEL expressions. Based on a patch by
>  Ben.
>
>It can be obtained from:
>https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.9/
>The Maven staging repo is:
>https://repository.apache.org/content/repositories/orgapachetomcat-1109/
>The svn tag is:
>http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_9/
>
>The proposed 8.5.9 release is:
>[ ] Broken - do not release
>[x] Stable - go ahead and release as 8.5.8
>

Felix
>-
>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