RE: 8.0.x / 7.0.x progress
Hi Niki, thank you for your reply. > -Original Message- > From: Niki Dokovski [mailto:nick...@gmail.com] > Sent: Saturday, October 5, 2013 7:47 AM > To: Tomcat Developers List > Subject: Re: 8.0.x / 7.0.x progress > > I have installed Wireshark now and can confirm that Firefox (after it is > > resumed) still sends data over the TCP connection which Tomcat seems not > to > > be able to read. > > > > Are there ACKs for the TCP packets? > I'll try to reproduce the case. Yes, I verified with Wireshark that Tomcat ACKs these packets correctly, but does not seem to be able to process them. I continued to send data from Firefox (SEQ went up to 61373) to ensure that the ACKs were not just resulting from buffering somewhere in the Windows or Java network stack, and I can confirm that Tomcat still ACKed these SEQ numbers. Note, that when using the BIO connector, everything works fine - the problems only appear with NIO or APR connector. > > > > B) For BIO connector: > > > > I noticed that on Tomcat with BIO connector, when using a > > > RemoteEndpoint.Async to asynchronously send data over the > WebSocket > > > connection, sendText(String, SendHandler) (or similar methods) will > > block if > > > the Remote endpoint does not read data from the connection, whereas > for > > > NIO and APR connector this method will always return immediately. > > > > Is it intended that for the BIO connector those methods are blocking? > > As > > > the javadoc says, "Initiates the asynchronous transmission of a text > > message. > > > This method returns before the message is transmitted.", I would have > > > expected that e.g. another Thread is used to write in blocking mode, so > > that > > > the sendText() method can return immediately. > > > > > > You can't do non-blocking IO with the BIO connector. All communication > > > with BIO is blocking. This is working as designed. > > > > OK, but my understanding was that there is a difference between the > terms > > "synchronous/asynchronous" and "blocking/non-blocking" (but maybe the > > meaning differs from programming language to programming language). > > > > An excellent and detailed explanation on this topic can be found in "UNIX > Network Programing" R. Stevens Vol 1 3td ed. p154-p160 Thank you for that information. However, currently I don't have that book (and I'm not very familiar with UNIX as I'm a windows guy ;) ), but please let me try to illustrate my use case with the Snake example. The SnakeTimer class has a broadcast() method that broadcasts a message to all connected clients by looping over them and calling snake.sendMessage(...), which in turn will call session.getBasicRemote().sendText(msg) to send the message. As the methods of RemoteEndpoint.Basic are blocking, this means that if some client establishes a Websocket connection and stops to read from it, then after some time the broadcast() method will hang waiting for sendText() to complete, which will block until that specific client continues to read data. This means that messages cannot be broadcasted to all other clients, so for them all snakes stop moving. A simple way that comes in my mind to solve this would be to use an additional thread for each connected client. This thread would take message from a Queue and send them to the client while the SnakeTimer's broadcast() would add a messages to the queue of each client. Then, if some client's sendText() method blocks (because the client does not read data from the connection), it does not interfere with the other clients, so they still would see the snakes moving. However, this is costly because it would require an additional thread per Websocket connection. So, another way would be to look at RemoteEndpoint.Async that can send messages asynchronously. The javadoc (from Oracle) of Async#sendText(String, SendHandler) says, "Initiates the asynchronous transmission of a text message. This method returns before the message is transmitted." For me, this looks like I can call this method and be sure that it does not block when some client does not read data from the websocket connection. Therefore, I could change the broadcast() method to use RemoteEndpoint.Async#sendText(String, SendHandler) to start async sending of a message, if no message is already on the way to the client (if it is, it would need to buffer them somewhere). Then, when SendHandler#onResult() callback is called, the code can look if it needs to send additional messages to the client (and if yes, call sendText(...) again). This will remove the need from using a separate thread for sending the data. The problem is now that if Tomcat's implementation of this Async#sendText(...) method is blocking when using the BIO connector, it will mean that with BIO I get the problem again that the snakes will stop moving on all clients if one client stops reading data (might be considered as a DoS), but if I use NIO or APR, everything will be fine. That
[Bug 49134] Server.stop() doesn't unregister all MBeans
https://issues.apache.org/bugzilla/show_bug.cgi?id=49134 Gael Lalire changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Gael Lalire --- With tomcat 7.0.42 Catalina.stop() doesn't unregister all MBeans registered by Catalina.start() for example : - Catalina:type=Realm,realmPath=/realm0/realm0 - Catalina:type=RequestProcessor* As there is no Catalina.destroy() what should I do ? -- 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 55629] New: StatusManagerServlet does not remove JMX notification listener
https://issues.apache.org/bugzilla/show_bug.cgi?id=55629 Bug ID: 55629 Summary: StatusManagerServlet does not remove JMX notification listener Product: Tomcat 7 Version: 7.0.42 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: gael.lal...@laposte.net StatusManagerServlet.destroy should call mBeanServer.removeNotificationListener because init method call mBeanServer.addNotificationListener. -- 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 55630] New: clean way to avoid setURLStreamHandlerFactory call
https://issues.apache.org/bugzilla/show_bug.cgi?id=55630
Bug ID: 55630
Summary: clean way to avoid setURLStreamHandlerFactory call
Product: Tomcat 7
Version: 7.0.42
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: gael.lal...@laposte.net
A current method is to set WebappLoader.first via reflection (because private).
I think the setURLStreamHandlerFactory should be move to Catalina.start
('first' static field can be move in Catalina).
So we could have a static method in Catalina to prevent
setURLStreamHandlerFactory call while first starting.
--
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: 8.0.x / 7.0.x progress
On Sat, Oct 5, 2013 at 4:56 PM, Konstantin Preißer wrote: > Hi Niki, > thank you for your reply. > > > -Original Message- > > From: Niki Dokovski [mailto:nick...@gmail.com] > > Sent: Saturday, October 5, 2013 7:47 AM > > To: Tomcat Developers List > > Subject: Re: 8.0.x / 7.0.x progress > > > > I have installed Wireshark now and can confirm that Firefox (after it > is > > > resumed) still sends data over the TCP connection which Tomcat seems > not > > to > > > be able to read. > > > > > > > Are there ACKs for the TCP packets? > > I'll try to reproduce the case. > > Yes, I verified with Wireshark that Tomcat ACKs these packets correctly, > but does not seem to be able to process them. I continued to send data from > Firefox (SEQ went up to 61373) to ensure that the ACKs were not just > resulting from buffering somewhere in the Windows or Java network stack, > and I can confirm that Tomcat still ACKed these SEQ numbers. > > Note, that when using the BIO connector, everything works fine - the > problems only appear with NIO or APR connector. > > > > > > > B) For BIO connector: > > > > > I noticed that on Tomcat with BIO connector, when using a > > > > RemoteEndpoint.Async to asynchronously send data over the > > WebSocket > > > > connection, sendText(String, SendHandler) (or similar methods) will > > > block if > > > > the Remote endpoint does not read data from the connection, whereas > > for > > > > NIO and APR connector this method will always return immediately. > > > > > Is it intended that for the BIO connector those methods are > blocking? > > > As > > > > the javadoc says, "Initiates the asynchronous transmission of a text > > > message. > > > > This method returns before the message is transmitted.", I would have > > > > expected that e.g. another Thread is used to write in blocking mode, > so > > > that > > > > the sendText() method can return immediately. > > > > > > > > You can't do non-blocking IO with the BIO connector. All > communication > > > > with BIO is blocking. This is working as designed. > > > > > > OK, but my understanding was that there is a difference between the > > terms > > > "synchronous/asynchronous" and "blocking/non-blocking" (but maybe the > > > meaning differs from programming language to programming language). > > > > > > > An excellent and detailed explanation on this topic can be found in > "UNIX > > Network Programing" R. Stevens Vol 1 3td ed. p154-p160 > > Thank you for that information. > However, currently I don't have that book (and I'm not very familiar with > UNIX as I'm a windows guy ;) ), but please let me try to illustrate my use > case with the Snake example. > > > The SnakeTimer class has a broadcast() method that broadcasts a message to > all connected clients by looping over them and calling > snake.sendMessage(...), which in turn will call > session.getBasicRemote().sendText(msg) to send the message. As the methods > of RemoteEndpoint.Basic are blocking, this means that if some client > establishes a Websocket connection and stops to read from it, then after > some time the broadcast() method will hang waiting for sendText() to > complete, which will block until that specific client continues to read > data. This means that messages cannot be broadcasted to all other clients, > so for them all snakes stop moving. > > A simple way that comes in my mind to solve this would be to use an > additional thread for each connected client. This thread would take message > from a Queue and send them to the client while the SnakeTimer's broadcast() > would add a messages to the queue of each client. Then, if some client's > sendText() method blocks (because the client does not read data from the > connection), it does not interfere with the other clients, so they still > would see the snakes moving. > > However, this is costly because it would require an additional thread per > Websocket connection. > > So, another way would be to look at RemoteEndpoint.Async that can send > messages asynchronously. The javadoc (from Oracle) of > Async#sendText(String, SendHandler) says, "Initiates the asynchronous > transmission of a text message. This method returns before the message is > transmitted." > For me, this looks like I can call this method and be sure that it does > not block when some client does not read data from the websocket > connection. Therefore, I could change the broadcast() method to use > RemoteEndpoint.Async#sendText(String, SendHandler) to start async sending > of a message, if no message is already on the way to the client (if it is, > it would need to buffer them somewhere). Then, when SendHandler#onResult() > callback is called, the code can look if it needs to send additional > messages to the client (and if yes, call sendText(...) again). > This will remove the need from using a separate thread for sending the > data. > > The problem is now that if Tomcat's implementation of this > Async#sendText(...) method is blocking when using the BIO c
Re: 8.0.x / 7.0.x progress
On 05/10/2013 14:56, Konstantin Preißer wrote: > Hi Niki, thank you for your reply. > >> -Original Message- From: Niki Dokovski >> [mailto:nick...@gmail.com] Sent: Saturday, October 5, 2013 7:47 AM >> To: Tomcat Developers List Subject: Re: 8.0.x / 7.0.x progress > >>> I have installed Wireshark now and can confirm that Firefox >>> (after it is resumed) still sends data over the TCP connection >>> which Tomcat seems not >> to >>> be able to read. >>> >> >> Are there ACKs for the TCP packets? I'll try to reproduce the >> case. > > Yes, I verified with Wireshark that Tomcat ACKs these packets > correctly, but does not seem to be able to process them. I continued > to send data from Firefox (SEQ went up to 61373) to ensure that the > ACKs were not just resulting from buffering somewhere in the Windows > or Java network stack, and I can confirm that Tomcat still ACKed > these SEQ numbers. > > Note, that when using the BIO connector, everything works fine - the > problems only appear with NIO or APR connector. OK. Create a Bugzilla entry for this one. It could be a Tomcat issue, it could also be lack of error handling in the snake example. >>> OK, but my understanding was that there is a difference between >>> the >> terms >>> "synchronous/asynchronous" and "blocking/non-blocking" (but maybe >>> the meaning differs from programming language to programming >>> language). There are but... WebSocket is built on top of Servlet 3.1 non-blocking IO. When you use the BIO connector the non-blocking IO API still works but it uses blocking IO. It might be possible to refactor the BIO aspect so the observed behaviour is more similar to NIO and APR/native but that will make scalability worse rather than better as now you'll have two threads per connection rather than one. > The problem is now that if Tomcat's implementation of this > Async#sendText(...) method is blocking when using the BIO connector, > it will mean that with BIO I get the problem again that the snakes > will stop moving on all clients if one client stops reading data > (might be considered as a DoS), but if I use NIO or APR, everything > will be fine. That would mean that I have to use different > implementations of broadcasting data to clients, depending on the > underlying connector that is being used (blocking or non-blocking). Or, don't use BIO. It is going to get removed at some point, possibly for Tomcat 9. There is a reason Tomcat 8 uses NIO by default and this is part of it. I'm leaning towards documentation being the way to address this - i.e. make clear that if you use the BIO connector then various NIO components either won't work (Comet) or will actually block (Servlet 3.1). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: 8.0.x / 7.0.x progress
Hi Mark, thanks for your reply. > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Saturday, October 5, 2013 9:00 PM > To: Tomcat Developers List > Subject: Re: 8.0.x / 7.0.x progress > OK. Create a Bugzilla entry for this one. It could be a Tomcat issue, it > could also be lack of error handling in the snake example. OK, will do. > >>> OK, but my understanding was that there is a difference between > >>> the > >> terms > >>> "synchronous/asynchronous" and "blocking/non-blocking" (but maybe > >>> the meaning differs from programming language to programming > >>> language). > > There are but... > > WebSocket is built on top of Servlet 3.1 non-blocking IO. When you use > the BIO connector the non-blocking IO API still works but it uses > blocking IO. > > It might be possible to refactor the BIO aspect so the observed > behaviour is more similar to NIO and APR/native but that will make > scalability worse rather than better as now you'll have two threads per > connection rather than one. > > The problem is now that if Tomcat's implementation of this > > Async#sendText(...) method is blocking when using the BIO connector, > > it will mean that with BIO I get the problem again that the snakes > > will stop moving on all clients if one client stops reading data > > (might be considered as a DoS), but if I use NIO or APR, everything > > will be fine. That would mean that I have to use different > > implementations of broadcasting data to clients, depending on the > > underlying connector that is being used (blocking or non-blocking). > > Or, don't use BIO. It is going to get removed at some point, possibly > for Tomcat 9. There is a reason Tomcat 8 uses NIO by default and this is > part of it. > > I'm leaning towards documentation being the way to address this - i.e. > make clear that if you use the BIO connector then various NIO components > either won't work (Comet) or will actually block (Servlet 3.1). OK, that makes sense to me. One question, would it be possible to make Session.getAsyncRemote() throw some RuntimeException when using the BIO connector, instead of silently using blocking writes? As the methods are in fact blocking with BIO (but it is documented that they are async), this may be a surprise to someone which doesn't know much about the BIO and NIO connectors of Tomcat when he relies on that methods being run asynchronously but in fact will be blocking, and then uses such an application in production (where the problems might not show up immediately when doing some tests). If getAsyncRemote() instead threw an exception saying that you need NIO or APR for this method, I think this might save someone such a surprise (but I must admit that I do not know much about Servlet 3.1's NIO features and how there the situation is with BIO connector). What do you think? Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 8.0.x / 7.0.x progress
On 05/10/2013 20:42, Konstantin Preißer wrote: > One question, would it be possible to make Session.getAsyncRemote() > throw some RuntimeException when using the BIO connector, instead of > silently using blocking writes? No. WebSocket is written on top of the Servlet 3.1 API. It has no access to Tomcat internals. > If getAsyncRemote() instead threw an exception saying that you need > NIO or APR for this method, I think this might save someone such a > surprise (but I must admit that I do not know much about Servlet > 3.1's NIO features and how there the situation is with BIO > connector). > > What do you think? I think breaking apps in this way is worse than using blocking IO. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1529537 - in /tomcat/trunk/java/org/apache: coyote/AbstractProtocol.java tomcat/util/net/AbstractEndpoint.java tomcat/util/net/SocketWrapper.java
Author: markt
Date: Sat Oct 5 22:21:40 2013
New Revision: 1529537
URL: http://svn.apache.org/r1529537
Log:
Make access of dispatcher list on socket wrapper thread safe
Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java
Modified: tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java?rev=1529537&r1=1529536&r2=1529537&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java Sat Oct 5
22:21:40 2013
@@ -18,6 +18,7 @@ package org.apache.coyote;
import java.io.IOException;
import java.net.InetAddress;
+import java.util.Iterator;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.Executor;
import java.util.concurrent.atomic.AtomicInteger;
@@ -616,14 +617,19 @@ public abstract class AbstractProtocol dispatches = null;
do {
-if (wrapper.hasNextDispatch()) {
-// Associate with the processor with the connection as
-// these calls may result in a nested call to process()
-connections.put(socket, processor);
-DispatchType nextDispatch = wrapper.getNextDispatch();
-state = processor.asyncDispatch(
-nextDispatch.getSocketStatus());
+if (dispatches != null) {
+if (dispatches.hasNext()) {
+// Associate with the processor with the
connection as
+// these calls may result in a nested call to
process()
+connections.put(socket, processor);
+DispatchType nextDispatch = dispatches.next();
+state = processor.asyncDispatch(
+nextDispatch.getSocketStatus());
+} else {
+dispatches = null;
+}
} else if (status == SocketStatus.DISCONNECT &&
!processor.isComet()) {
// Do nothing here, just wait for it to get recycled
@@ -670,9 +676,12 @@ public abstract class AbstractProtocolhttp://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1529537&r1=1529536&r2=1529537&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Sat Oct
5 22:21:40 2013
@@ -23,6 +23,7 @@ import java.net.InetSocketAddress;
import java.security.PrivilegedAction;
import java.util.ArrayList;
import java.util.HashMap;
+import java.util.Iterator;
import java.util.StringTokenizer;
import java.util.concurrent.Executor;
import java.util.concurrent.TimeUnit;
@@ -636,13 +637,11 @@ public abstract class AbstractEndpoint socketWrapper) {
-// Synchronise on the socket wrapper to ensure no other threads are
-// working with the socket
-synchronized (socketWrapper) {
-while (socketWrapper.hasNextDispatch()) {
-DispatchType dispatchType = socketWrapper.getNextDispatch();
-processSocket(socketWrapper, dispatchType.getSocketStatus(),
false);
-}
+Iterator dispatches =
socketWrapper.getIteratorAndClearDispatches();
+
+while (dispatches.hasNext()) {
+DispatchType dispatchType = dispatches.next();
+processSocket(socketWrapper, dispatchType.getSocketStatus(),
false);
}
}
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java?rev=1529537&r1=1529536&r2=1529537&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java Sat Oct 5
22:21:40 2013
@@ -17,8 +17,8 @@
package org.apache.tomcat.util.net;
import java.util.Iterator;
-import java.util.LinkedHashSet;
import java.util.Set;
+import java.util.concurrent.CopyOnWriteArraySet;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
@@ -62,7 +62,7 @@ public class SocketWrapper {
*/
private final Object writeThreadLock = new Object();
-private Set dis
[Bug 55630] clean way to avoid setURLStreamHandlerFactory call
https://issues.apache.org/bugzilla/show_bug.cgi?id=55630 Mark Thomas changed: What|Removed |Added Component|Catalina|Catalina Version|7.0.42 |trunk Product|Tomcat 7|Tomcat 8 Target Milestone|--- | --- Comment #1 from Mark Thomas --- This isn't going to be changed for 7.0.x or 6.0.x but we should consider it for 8.0.x. -- 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
Need tomcat-native 1.1.29 for next 8.0.x/7.0.x releases
Sorry to be a pain. The JSR 356 WebSocket implementation is broken with APR prior to r1525525 [1]. Tomcat 7.0.x and Tomcat 8.0.x need a 1.1.29 native release to pick up this fix. Any takers for the release? Thanks, Mark [1] http://svn.apache.org/viewvc?view=revision&revision=1525525 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1529546 - in /tomcat/trunk: java/org/apache/catalina/realm/CombinedRealm.java test/org/apache/catalina/mbeans/TestRegistration.java
Author: markt
Date: Sat Oct 5 22:53:05 2013
New Revision: 1529546
URL: http://svn.apache.org/r1529546
Log:
Partial fix for re-opened
https://issues.apache.org/bugzilla/show_bug.cgi?id=49134
Ensure nested realms are correctly destroyed, ensuring that the associated
MBeans are deregistered.
Modified:
tomcat/trunk/java/org/apache/catalina/realm/CombinedRealm.java
tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Modified: tomcat/trunk/java/org/apache/catalina/realm/CombinedRealm.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm/CombinedRealm.java?rev=1529546&r1=1529545&r2=1529546&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/realm/CombinedRealm.java (original)
+++ tomcat/trunk/java/org/apache/catalina/realm/CombinedRealm.java Sat Oct 5
22:53:05 2013
@@ -245,6 +245,20 @@ public class CombinedRealm extends Realm
/**
+ * Ensure child Realms are destroyed when this Realm is destroyed.
+ */
+@Override
+protected void destroyInternal() throws LifecycleException {
+for (Realm realm : realms) {
+if (realm instanceof Lifecycle) {
+((Lifecycle) realm).destroy();
+}
+}
+super.destroyInternal();
+}
+
+
+/**
* Return the Principal associated with the specified chain of X509
* client certificates. If there is none, return null.
*
Modified: tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java?rev=1529546&r1=1529545&r2=1529546&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java Sat Oct
5 22:53:05 2013
@@ -33,7 +33,11 @@ import static org.junit.Assert.fail;
import org.junit.Test;
+import org.apache.catalina.Context;
+import org.apache.catalina.Realm;
import org.apache.catalina.core.StandardHost;
+import org.apache.catalina.realm.CombinedRealm;
+import org.apache.catalina.realm.NullRealm;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.startup.TomcatBaseTest;
import org.apache.tomcat.util.modeler.Registry;
@@ -108,6 +112,10 @@ public class TestRegistration extends To
",host=" + host,
"Tomcat:type=WebResourceRoot,context=" + context +
",host=" + host,
+"Tomcat:type=Realm,realmPath=/realm0,context=" + context +
+",host=" + host,
+"Tomcat:type=Realm,realmPath=/realm0/realm0,context=" + context +
+",host=" + host,
};
}
@@ -146,7 +154,13 @@ public class TestRegistration extends To
if (!contextDir.mkdirs() && !contextDir.isDirectory()) {
fail("Failed to create: [" + contextDir.toString() + "]");
}
-tomcat.addContext(contextName, contextDir.getAbsolutePath());
+Context ctx = tomcat.addContext(contextName,
contextDir.getAbsolutePath());
+
+CombinedRealm combinedRealm = new CombinedRealm();
+Realm nullRealm = new NullRealm();
+combinedRealm.addRealm(nullRealm);
+ctx.setRealm(combinedRealm);
+
tomcat.start();
// Verify there are no Catalina MBeans
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1529547 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/realm/CombinedRealm.java test/org/apache/catalina/mbeans/TestRegistration.java webapps/docs/changelog.xml
Author: markt
Date: Sat Oct 5 22:55:25 2013
New Revision: 1529547
URL: http://svn.apache.org/r1529547
Log:
Partial fix for re-opened
https://issues.apache.org/bugzilla/show_bug.cgi?id=49134
Ensure nested realms are correctly destroyed, ensuring that the associated
MBeans are deregistered.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1529546
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java?rev=1529547&r1=1529546&r2=1529547&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/realm/CombinedRealm.java Sat
Oct 5 22:55:25 2013
@@ -232,6 +232,20 @@ public class CombinedRealm extends Realm
/**
+ * Ensure child Realms are destroyed when this Realm is destroyed.
+ */
+@Override
+protected void destroyInternal() throws LifecycleException {
+for (Realm realm : realms) {
+if (realm instanceof Lifecycle) {
+((Lifecycle) realm).destroy();
+}
+}
+super.destroyInternal();
+}
+
+
+/**
* Return the Principal associated with the specified chain of X509
* client certificates. If there is none, return null.
*
Modified:
tomcat/tc7.0.x/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/mbeans/TestRegistration.java?rev=1529547&r1=1529546&r2=1529547&view=diff
==
--- tomcat/tc7.0.x/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
(original)
+++ tomcat/tc7.0.x/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Sat Oct 5 22:55:25 2013
@@ -33,7 +33,11 @@ import static org.junit.Assert.fail;
import org.junit.Test;
+import org.apache.catalina.Context;
+import org.apache.catalina.Realm;
import org.apache.catalina.core.StandardHost;
+import org.apache.catalina.realm.CombinedRealm;
+import org.apache.catalina.realm.NullRealm;
import org.apache.catalina.startup.Tomcat;
import org.apache.catalina.startup.TomcatBaseTest;
import org.apache.tomcat.util.modeler.Registry;
@@ -106,6 +110,10 @@ public class TestRegistration extends To
",host=" + host + ",name=StandardContextValve",
"Tomcat:type=WebappClassLoader,context=" + context +
",host=" + host,
+"Tomcat:type=Realm,realmPath=/realm0,context=" + context +
+",host=" + host,
+"Tomcat:type=Realm,realmPath=/realm0/realm0,context=" + context +
+",host=" + host,
};
}
@@ -146,7 +154,13 @@ public class TestRegistration extends To
if (!contextDir.mkdirs() && !contextDir.isDirectory()) {
fail("Failed to create: [" + contextDir.toString() + "]");
}
-tomcat.addContext(contextName, contextDir.getAbsolutePath());
+Context ctx = tomcat.addContext(contextName,
contextDir.getAbsolutePath());
+
+CombinedRealm combinedRealm = new CombinedRealm();
+Realm nullRealm = new NullRealm();
+combinedRealm.addRealm(nullRealm);
+ctx.setRealm(combinedRealm);
+
tomcat.start();
// Verify there are no Catalina MBeans
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1529547&r1=1529546&r2=1529547&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Sat Oct 5 22:55:25 2013
@@ -64,6 +64,11 @@
IOException may be in response to the client continuing to send a
message after the server sent a close control message. (markt)
+
+49134: Ensure nested realms are correctly destroyed, when a
+CombinedRealm is destroyed. This ensures that the associated MBeans are
+deregistered. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 49134] Server.stop() doesn't unregister all MBeans
https://issues.apache.org/bugzilla/show_bug.cgi?id=49134 --- Comment #5 from Mark Thomas --- I've fixed the realm MBean issues in 7.0.x and 8.0.x (the CombinedRealm wasn't destroying nested Realms). I'll look at the RequestProcessor MBeans next. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1529549 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Author: markt
Date: Sat Oct 5 23:18:14 2013
New Revision: 1529549
URL: http://svn.apache.org/r1529549
Log:
Extend the test case to cover RequestProcessors
Modified:
tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Modified: tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java?rev=1529549&r1=1529548&r2=1529549&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
(original)
+++ tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java Sat Oct
5 23:18:14 2013
@@ -96,6 +96,14 @@ public class TestRegistration extends To
}
}
+private static String[] requestMBeanNames(String port, String type) {
+return new String[] {
+"Tomcat:type=RequestProcessor,worker=" +
+ObjectName.quote("http-" + type + "-" + ADDRESS + "-" +
port) +
+",name=HttpRequest1",
+};
+}
+
private static String[] contextMBeanNames(String host, String context) {
return new String[] {
"Tomcat:j2eeType=WebModule,name=//" + host + context +
@@ -163,6 +171,8 @@ public class TestRegistration extends To
tomcat.start();
+getUrl("http://localhost:"; + getPort());
+
// Verify there are no Catalina MBeans
onames = mbeanServer.queryNames(new ObjectName("Catalina:*"), null);
log.info(MBeanDumper.dumpBeans(mbeanServer, onames));
@@ -176,8 +186,7 @@ public class TestRegistration extends To
}
// Create the list of expected MBean names
-String protocol=
-getTomcatInstance().getConnector().getProtocolHandlerClassName();
+String protocol = tomcat.getConnector().getProtocolHandlerClassName();
if (protocol.indexOf("Nio") > 0) {
protocol = "nio";
} else if (protocol.indexOf("Apr") > 0) {
@@ -185,12 +194,14 @@ public class TestRegistration extends To
} else {
protocol = "bio";
}
-String index =
getTomcatInstance().getConnector().getProperty("nameIndex").toString();
+String index =
tomcat.getConnector().getProperty("nameIndex").toString();
ArrayList expected = new
ArrayList<>(Arrays.asList(basicMBeanNames()));
expected.addAll(Arrays.asList(hostMBeanNames("localhost")));
expected.addAll(Arrays.asList(contextMBeanNames("localhost",
contextName)));
expected.addAll(Arrays.asList(connectorMBeanNames("auto-" + index,
protocol)));
expected.addAll(Arrays.asList(optionalMBeanNames("localhost")));
+expected.addAll(Arrays.asList(requestMBeanNames(
+"auto-" + index + "-" + getPort(), protocol)));
// Did we find all expected MBeans?
ArrayList missing = new ArrayList<>(expected);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 49134] Server.stop() doesn't unregister all MBeans
https://issues.apache.org/bugzilla/show_bug.cgi?id=49134 Mark Thomas changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #6 from Mark Thomas --- I can't reproduce the RequestProcessor issue. Please provide the simplest possible test case to reproduce - ideally as a patch to the existing unit test. See http://svn.apache.org/r1529546 and http://svn.apache.org/r1529549 for some examples of extending that test case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a new failure on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1449 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1529547 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[Bug 55633] New: [websocket] Tomcat can't read data from the client when the client temporarily pauses
https://issues.apache.org/bugzilla/show_bug.cgi?id=55633
Bug ID: 55633
Summary: [websocket] Tomcat can't read data from the client
when the client temporarily pauses
Product: Tomcat 8
Version: trunk
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: WebSocket
Assignee: dev@tomcat.apache.org
Reporter: kpreis...@apache.org
As reported on Re: 8.0.x / 7.0.x progress thread [1]:
For NIO and APR connector:
It seems that when a client establishes a Websocket connection and then stops
to read data from it (but doesn't close the connection, so that at Tomcat's
side writing data to the underlying TCP connection will be blocked), and then
after some time the client continues to read data from the Websocket
connection, then Tomcat seems not to be able to read data from that client any
more (and doesn't notice when the connection has been closed), but it can still
write data to the client.
To reproduce:
Update trunk to r1529443.
Then apply the following patch locally to make the issue easier to reproduce
(by blowing the amount of data that Tomcat sends to the client):
Index: webapps/examples/WEB-INF/classes/websocket/snake/SnakeTimer.java
===
--- webapps/examples/WEB-INF/classes/websocket/snake/SnakeTimer.java
(revision 1529443)
+++ webapps/examples/WEB-INF/classes/websocket/snake/SnakeTimer.java
(working copy)
@@ -73,8 +73,10 @@
sb.append(',');
}
}
-broadcast(String.format("{\"type\": \"update\", \"data\" : [%s]}",
-sb.toString()));
+char[] random = new char[8192];
+java.util.Arrays.fill(random, 'x');
+broadcast(String.format("{\"type\": \"update\", \"data\" : [%s],
\"randomData\": \"[%s]\"}",
+sb.toString(), new String(random)));
}
protected static void broadcast(String message) {
1) Start Tomcat (current trunk) on Windows 64-bit with Java7 64-bit and either
NIO or APR connector.
2) Start IE (10+) and Firefox and with both browsers open the snake example. On
both browsers, press up or down key so that both snakes begin moving.
3) Suspend the Firefox processes. This can be done with "Process Explorer" [2]
tool by right-clicking on the firefox.exe entry and select "Suspend". You can
see that Firefox does not respond any more, but on IE the snakes continue to
move.
4) After some seconds, you can see that on IE the snakes suddenly stop moving.
This is correct because the current code uses RemoteEndpoint.Basic that may
block on write() methods.
5) Now resume Firefox with Process Explorer. You can see that on both browsers
the snakes will continue to move. This means that both browsers are able to
receive data from the Websocket connection.
6) When you try to change the direction of the snake in IE, everything works.
However on Firefox, the snake will not change its direction. This means that
while Tomcat continues to send data to this Websocket connection, it cannot
receive from it any more.
7) If you close Firefox, then the corresponding snake will not disappear (so it
seems Tomcat doesn't notice that the connection closed).
Note: This only applies to the NIO and APR connectors - with BIO, the problem
doesn't occur.
With Wireshark you can see that FF still sends the direction data correctly and
Tomcat ACKs the packets, but does not seem to be able to process them.
[1] http://markmail.org/message/z6qklqiceyftapfx
[2] http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
--
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: 8.0.x / 7.0.x progress
Hi Mark, > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Saturday, October 5, 2013 9:46 PM > To: Tomcat Developers List > Subject: Re: 8.0.x / 7.0.x progress > > On 05/10/2013 20:42, Konstantin Preißer wrote: > > > One question, would it be possible to make Session.getAsyncRemote() > > throw some RuntimeException when using the BIO connector, instead of > > silently using blocking writes? > > No. WebSocket is written on top of the Servlet 3.1 API. It has no access > to Tomcat internals. > > > If getAsyncRemote() instead threw an exception saying that you need > > NIO or APR for this method, I think this might save someone such a > > surprise (but I must admit that I do not know much about Servlet > > 3.1's NIO features and how there the situation is with BIO > > connector). > > > > What do you think? > > I think breaking apps in this way is worse than using blocking IO. OK, thank you for your explanation. (Personally I'm not convinced of this yet - I would think getting exceptions on getAsyncRemote() is more safe then silently risk a DoS (but I probably do not have as much knowledge and experience to fully understand the consequences) - but as you say Websocket has no access to Tomcat's internals so it doesn't matter either.) When I was writing the bug report for the websocket problems with NIO and APR connector [1], I updated trunk to the current revision, and after I started Tomcat with NIO and opened the snakes example, I got corrupt data on Firefox and exceptions on Tomcat like the following: 06-Oct-2013 03:44:34.083 SEVERE [http-nio-8080-exec-2] org.apache.tomcat.websocket.pojo.PojoEndpointBase.onError Failed to call onError method of POJO end point for POJO of type [websocket.snake.SnakeAnnotation] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.onError(PojoEndpointBase.java:131) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.handleOnOpenError(PojoEndpointBase.java:91) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:71) at org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:70) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:129) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1620) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1578) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: java.nio.charset.CoderMalfunctionError: java.nio.BufferOverflowException at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:565) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:620) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:197) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:154) at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37) at websocket.snake.Snake.sendMessage(Snake.java:66) at websocket.snake.SnakeTimer.broadcast(SnakeTimer.java:83) at websocket.snake.SnakeAnnotation.onOpen(SnakeAnnotation.java:90) at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:58) ... 9 more Caused by: java.nio.BufferOverflowException at java.nio.Buffer.nextPutIndex(Buffer.java:513) at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:163) at org.apache.tomcat.util.buf.Utf8Encoder.encodeNotHasArray(Utf8Encoder.java:169) at org.apache.tomcat.util.buf.Utf8Encoder.encodeLoop(Utf8Encoder.java:40) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561) ... 20 more 06-Oct-2013 03:44:34.486 SEVERE [http-nio-8080-exec-2] org.apache.tomcat.websocket.pojo.Pojo
[Bug 55633] [websocket] Tomcat can't read data from the client after the client temporarily pauses
https://issues.apache.org/bugzilla/show_bug.cgi?id=55633 Konstantin Preißer changed: What|Removed |Added Summary|[websocket] Tomcat can't|[websocket] Tomcat can't |read data from the client |read data from the client |when the client temporarily |after the client |pauses |temporarily pauses 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
[GUMP@vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Timed Out'. For reference only, the following projects are affected by this: - tomcat-trunk-test : 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/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on junit exists, no need to add for property hamcrest.jar. -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. -DEBUG- Dependency on tomcat-trunk exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build timed out -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 60 mins 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/dist/junit-20131006.jar -Dobjenesis.jar=/srv/gump/public/workspace/objenesis/main/target/objenesis-2.1-SNAPSHOT.jar -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20131006-native-src.tar.gz -Dexamples.sources.skip=true -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20131006.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20131006-native-src.tar.gz -Dtest.accesslog=true -Dcommons-pool.home=/srv/gump/public/workspace/apache-commons/pool -Dcommons-dbcp.home=/ srv/gump/public/workspace/apache-commons/dbcp -Deasymock.jar=/srv/gump/public/workspace/easymock/easymock/target/easymock-3.3-SNAPSHOT.jar -Dhamcrest.jar=/srv/gump/public/workspace/junit/dist/junit-20131006.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/servle t-api.jar:/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-jni.jar:/srv/gump/public/workspace/tomcat -trunk/output/build/lib/tomcat-spd
