Re: svn commit: r1484923 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
On 21/05/2013 23:10, Konstantin Kolinko wrote:
2013/5/22 ma...@apache.org:
Author: markt
Date: Tue May 21 20:01:02 2013
New Revision: 1484923
URL: http://svn.apache.org/r1484923
Log:
Make deletion of the copied WARs used for anti-resource locking more robust
if the context fails to start (there were some circumstances where the
original WAR could get deleted).
@@ -942,11 +940,8 @@ public class ContextConfig
String docBase = context.getDocBase();
if (docBase == null)
return;
-if (originalDocBase == null) {
-originalDocBase = docBase;
-} else {
-docBase = originalDocBase;
-}
+originalDocBase = docBase;
+
2. Why if(originalDocBase == null) check was removed?
It was part of the rotating the original and modified values. Now we
just keep copies of both it the check is irrelevant.
1. This change in 6.0 needs to go through voting
Sorry - I was on automatic pilot when doing my back-ports.
Clearly there is a +1 from me. If two other folks +1 it fairly soon I'll
just leave it. If not, I'll revert it and add it to the status file.
2. There is a bug in the above line,
docBase should not be there.
(Though it never executes, as antiLockingDocBase was created as
file.getAbsolutePath(),)
It will allow to simplify this block a bit.
I'll clean that up in trunk and 7.0.x and propose it for 6.0.x.
3. Wouldn't it be more simple to have the new field as a File instead of
String?
While docBase is a String, per API, this field represents a proper file.
Yes. That allows a few more lines to be removed.
Thanks for the review.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485114 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Wed May 22 08:42:14 2013
New Revision: 1485114
URL: http://svn.apache.org/r1485114
Log:
Clean-up / simplify based on review by kkolinko.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1485114r1=1485113r2=1485114view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Wed May 22
08:42:14 2013
@@ -215,7 +215,7 @@ public class ContextConfig implements Li
/**
* Anti-locking docBase
*/
-private String antiLockingDocBase = null;
+private File antiLockingDocBase = null;
/**
@@ -727,28 +727,28 @@ public class ContextConfig implements Li
ContextName cn = new ContextName(path, context.getWebappVersion());
docBase = cn.getBaseName();
-File file = null;
if (originalDocBase.toLowerCase(Locale.ENGLISH).endsWith(.war)) {
-file = new File(System.getProperty(java.io.tmpdir),
+antiLockingDocBase = new File(
+System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase + .war);
} else {
-file = new File(System.getProperty(java.io.tmpdir),
+antiLockingDocBase = new File(
+System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase);
}
if (log.isDebugEnabled()) {
log.debug(Anti locking context[ + context.getName()
-+ ] setting docBase to + file);
++ ] setting docBase to +
+antiLockingDocBase.getAbsolutePath());
}
-antiLockingDocBase = file.getAbsolutePath();
// Cleanup just in case an old deployment is lying around
-ExpandWar.delete(file);
-if (ExpandWar.copy(docBaseFile, file)) {
-context.setDocBase(antiLockingDocBase);
+ExpandWar.delete(antiLockingDocBase);
+if (ExpandWar.copy(docBaseFile, antiLockingDocBase)) {
+context.setDocBase(antiLockingDocBase.getAbsolutePath());
}
}
-
}
@@ -993,15 +993,9 @@ public class ContextConfig implements Li
}
// Remove (partially) folders and files created by antiLocking
-Host host = (Host) context.getParent();
-String docBase = context.getDocBase();
if (antiLockingDocBase != null) {
-File docBaseFile = new File(antiLockingDocBase);
-if (!docBaseFile.isAbsolute()) {
-docBaseFile = new File(host.getAppBaseFile(), docBase);
-}
// No need to log failure - it is expected in this case
-ExpandWar.delete(docBaseFile, false);
+ExpandWar.delete(antiLockingDocBase, false);
}
// Reset ServletContextInitializer scanning
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485115 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed May 22 08:44:41 2013 New Revision: 1485115 URL: http://svn.apache.org/r1485115 Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1485115r1=1485114r2=1485115view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed May 22 08:44:41 2013 @@ -31,6 +31,13 @@ PATCHES ACCEPTED TO BACKPORT: PATCHES PROPOSED TO BACKPORT: [ New proposals should be added at the end of the list ] +* Clean-up recording of location where WAR is copied when using anti-locking + features of a Context + http://svn.apache.org/r1485114 + +1: markt + -1: + + PATCHES/ISSUES THAT ARE STALLED * Backport JSP unloading patch (BZ48358). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485117 - /tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Wed May 22 08:46:58 2013
New Revision: 1485117
URL: http://svn.apache.org/r1485117
Log:
Clean-up / simplify based on review by kkolinko.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1485117r1=1485116r2=1485117view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java
Wed May 22 08:46:58 2013
@@ -233,7 +233,7 @@ public class ContextConfig implements Li
/**
* Anti-locking docBase
*/
-private String antiLockingDocBase = null;
+private File antiLockingDocBase = null;
/**
@@ -794,27 +794,27 @@ public class ContextConfig implements Li
ContextName cn = new ContextName(path, context.getWebappVersion());
docBase = cn.getBaseName();
-File file = null;
if (originalDocBase.toLowerCase(Locale.ENGLISH).endsWith(.war)) {
-file = new File(System.getProperty(java.io.tmpdir),
+antiLockingDocBase = new File(
+System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase + .war);
} else {
-file = new File(System.getProperty(java.io.tmpdir),
+antiLockingDocBase = new File(
+System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase);
}
if (log.isDebugEnabled())
log.debug(Anti locking context[ + context.getName()
-+ ] setting docBase to + file);
++ ] setting docBase to +
+antiLockingDocBase.getAbsolutePath());
-antiLockingDocBase = file.getAbsolutePath();
// Cleanup just in case an old deployment is lying around
-ExpandWar.delete(file);
-if (ExpandWar.copy(docBaseFile, file)) {
-context.setDocBase(antiLockingDocBase);
+ExpandWar.delete(antiLockingDocBase);
+if (ExpandWar.copy(docBaseFile, antiLockingDocBase)) {
+context.setDocBase(antiLockingDocBase.getAbsolutePath());
}
}
-
}
@@ -1056,16 +1056,9 @@ public class ContextConfig implements Li
}
// Remove (partially) folders and files created by antiLocking
-Host host = (Host) context.getParent();
-String appBase = host.getAppBase();
-String docBase = context.getDocBase();
if (antiLockingDocBase != null) {
-File docBaseFile = new File(antiLockingDocBase);
-if (!docBaseFile.isAbsolute()) {
-docBaseFile = new File(appBase, docBase);
-}
// No need to log failure - it is expected in this case
-ExpandWar.delete(docBaseFile, false);
+ExpandWar.delete(antiLockingDocBase, false);
}
// Reset ServletContextInitializer scanning
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Automatic deployment changes
On 21/05/2013 23:42, Konstantin Kolinko wrote:
Finally trying to find some time to review this...
1) Is there an intent to put [4] into some version-controlled place?
E.g. webapps/docs/architecture/ ?
Or essentials of it will be included as part of config/context.html ?
I see some rows from the tables are copied as comments into
TestHostConfigAutomaticDeployment.java
Yes it will be included somewhere. I'm not exactly sure where yet. I
think some re-organising of the documentation will be required.
2) A pair of typos:
s/ content.xml / [appname].xml / (or at least context.xml)
s/ Redploy / Redeploy /
Thanks. Fixed.
3) It is possible to deploy a context by specifying it in server.xml.
I think such a context can be a allowed to reload, but it would be bad
to autoredeploy it (one should place such webapp outside of appbase).
What happens with it if ${catalina.base}/conf/context.xml is touched?
I need to do some testing with this.
4) I am a bit missing a legend for the tables.
The first table lists what artifacts (XML, WAR, DIR) are present in
every scenario?
I've tried to clarify it. The order was. Starting point, settings, result.
5) There exists unpackWAR attribute on a Context, which is not mentioned
here.
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
There are some tests for that. I'm planning on adding an equivalent
context setting for copyXML to address one of the use cases from the
users list.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 48358] JSP-unloading reloaded
https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 vivekpandyan vivekpandya...@gmail.com changed: What|Removed |Added Priority|P2 |P4 Component|Jasper |Manager application OS|Linux |Windows XP -- 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: WebSockets in Tomcat 8 (proxy support and ssl handshake)
On Tue, May 21, 2013 at 3:15 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 5:09 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 3:45 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, May 17, 2013 at 3:53 PM, Niki Dokovski nick...@gmail.comwrote: On Fri, May 17, 2013 at 3:35 PM, Mark Thomas ma...@apache.org wrote: On 17/05/2013 13:07, Niki Dokovski wrote: Hi, Developing some sample apps with websockets and tomcat 8 revealed two issues I’d like to discuss here. 1. There is no proxy support in the implementation of WebSocketContainer.connectToServer calls. While playing around with the code it was relatively easy to add this in the implementation with simple consideration of http.proxyHost and Port system properties; replacing host and port values which were obtained from path method parameter and making initial HTTP CONNECT message to the proxy. In this case, do you think we can add proxy support here? I was thinking how to provide some kind of automation test as well, but no luck so far. Personally I dislike the global nature system properties for configuration unless they are absolutely the only option. Since the WebSocket API has no way of setting a proxy at the moment, system properties might be the only choice :( This is an issue you should raise with the WebSocket EG group. I suggest opening a Jira to request proxy support in a future version. https://java.net/jira/browse/WEBSOCKET_SPEC Here is the issue: https://java.net/jira/browse/WEBSOCKET_SPEC-202 2. So when I got my proxy tunneling in place (with the CONNECT http request) I hit a tougher problem with SSL handshake implementation in WebSocketSslHandshakeThread. The SSL handshake was successful while I was stepping with the debugger through the code and failed when I run the test. It should be some timing issue. This bit needs more debugging. Have you seen this before? No, but the SSL support for WebSocket clients hasn't been heavily used yet so there could still be some bugs to iron out. If you haven't already, take a look at TestWsWebSocketContainer.testConnectToServerEndpointSSL() Mark Thanks. I'll take a look at it. Doing some debugging in the implementation of AsyncChannelWeapperSecure.WebSocketSslHandshakeThread run() revealed that by having small timeout (thread sleep) in NEED_WRAP case, allows SSL handshake to complete successfully. (This is still the case when there is a HTTP Proxy tunnel established between Endpoints) This is not the solution for the problem, of course. Here I attach some sysout logs with working and non-working flows. 1. working example: after sending initial message sleep the executing thread in need_wrap case for little and you get following sequence write: 154 write done: true NEED_UNWRAP read: 2357 read done: true SSL Handshake is OK 2. non working example write: 154 write done: true NEED_UNWRAP read: 1460 much less bytes to consider read done: true ... Exception Any comments? getting closer as the error condition is caused by BUFFER_UNDERFLOW state. Will try to read again in this condition. Basically there is no enough bytes to construct the message in SSLEngine. OK that does the trick. Here is a bug on the issue https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 I'll try to polish a bit and send a small code snippet solving BUFFER_UNDERFLOW case for discussion. cheers Niki Here are two patches for http proxy support (WsWebSocketContainer) and buffer underflow (AsyncChannelWrapperSecure) fix respectively. I'd like to ask for your comments. cheers Niki - 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: WebSockets in Tomcat 8 (proxy support and ssl handshake)
2013/5/22 Niki Dokovski nick...@gmail.com: On Tue, May 21, 2013 at 3:15 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 5:09 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 3:45 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, May 17, 2013 at 3:53 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, May 17, 2013 at 3:35 PM, Mark Thomas ma...@apache.org wrote: On 17/05/2013 13:07, Niki Dokovski wrote: Hi, Developing some sample apps with websockets and tomcat 8 revealed two issues I’d like to discuss here. 1. There is no proxy support in the implementation of WebSocketContainer.connectToServer calls. While playing around with the code it was relatively easy to add this in the implementation with simple consideration of http.proxyHost and Port system properties; replacing host and port values which were obtained from path method parameter and making initial HTTP CONNECT message to the proxy. In this case, do you think we can add proxy support here? I was thinking how to provide some kind of automation test as well, but no luck so far. Personally I dislike the global nature system properties for configuration unless they are absolutely the only option. Since the WebSocket API has no way of setting a proxy at the moment, system properties might be the only choice :( This is an issue you should raise with the WebSocket EG group. I suggest opening a Jira to request proxy support in a future version. https://java.net/jira/browse/WEBSOCKET_SPEC Here is the issue: https://java.net/jira/browse/WEBSOCKET_SPEC-202 2. So when I got my proxy tunneling in place (with the CONNECT http request) I hit a tougher problem with SSL handshake implementation in WebSocketSslHandshakeThread. The SSL handshake was successful while I was stepping with the debugger through the code and failed when I run the test. It should be some timing issue. This bit needs more debugging. Have you seen this before? No, but the SSL support for WebSocket clients hasn't been heavily used yet so there could still be some bugs to iron out. If you haven't already, take a look at TestWsWebSocketContainer.testConnectToServerEndpointSSL() Mark Thanks. I'll take a look at it. Doing some debugging in the implementation of AsyncChannelWeapperSecure.WebSocketSslHandshakeThread run() revealed that by having small timeout (thread sleep) in NEED_WRAP case, allows SSL handshake to complete successfully. (This is still the case when there is a HTTP Proxy tunnel established between Endpoints) This is not the solution for the problem, of course. Here I attach some sysout logs with working and non-working flows. 1. working example: after sending initial message sleep the executing thread in need_wrap case for little and you get following sequence write: 154 write done: true NEED_UNWRAP read: 2357 read done: true SSL Handshake is OK 2. non working example write: 154 write done: true NEED_UNWRAP read: 1460 much less bytes to consider read done: true ... Exception Any comments? getting closer as the error condition is caused by BUFFER_UNDERFLOW state. Will try to read again in this condition. Basically there is no enough bytes to construct the message in SSLEngine. OK that does the trick. Here is a bug on the issue https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 I'll try to polish a bit and send a small code snippet solving BUFFER_UNDERFLOW case for discussion. cheers Niki Here are two patches for http proxy support (WsWebSocketContainer) and buffer underflow (AsyncChannelWrapperSecure) fix respectively. I'd like to ask for your comments. Patches should be posted to Bugzilla. The mailing list server strips attachments (unless they have proper mime-type, etc. etc.) cheers Niki - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54997] SSL Handshake implementation in AsycnChannelWrapperSecure does not handle SSLEngineResult.Status.BUFFER_UNDERFLOW and SSLEngineResult.Status.BUFFER_OVERFLOW states
https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 --- Comment #1 from Niki Dokovski nick...@gmail.com --- Created attachment 30309 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30309action=edit patch in AsyncChannelWrapperSecure.java illustrating a potential improvement in handling the buffer underflow state -- 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 48358] JSP-unloading reloaded
https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 Rainer Jung rainer.j...@kippdata.de changed: What|Removed |Added Priority|P4 |P2 Component|Manager application |Jasper Hardware|Other |All OS|Windows XP |All -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55006] New: Add http proxy support for ClientEndpoint using system properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=55006 Bug ID: 55006 Summary: Add http proxy support for ClientEndpoint using system properties Product: Tomcat 8 Version: trunk Hardware: PC Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: nick...@gmail.com Classification: Unclassified Currently there is no support for utilization of http proxy for ClientEndpoints. Here is a patch that illustrates the usage of http(s).proxy(Host)(Port) system properties. A request for improvement in WebSocket JSR 356 can be found here https://java.net/jira/browse/WEBSOCKET_SPEC-202 -- 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 55006] Add http proxy support for ClientEndpoint using system properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=55006 --- Comment #1 from Niki Dokovski nick...@gmail.com --- Created attachment 30310 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30310action=edit patch in WsWebSocketContainer -- 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: WebSockets in Tomcat 8 (proxy support and ssl handshake)
On Wed, May 22, 2013 at 1:48 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2013/5/22 Niki Dokovski nick...@gmail.com: On Tue, May 21, 2013 at 3:15 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 5:09 PM, Niki Dokovski nick...@gmail.com wrote: On Mon, May 20, 2013 at 3:45 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, May 17, 2013 at 3:53 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, May 17, 2013 at 3:35 PM, Mark Thomas ma...@apache.org wrote: On 17/05/2013 13:07, Niki Dokovski wrote: Hi, Developing some sample apps with websockets and tomcat 8 revealed two issues I’d like to discuss here. 1. There is no proxy support in the implementation of WebSocketContainer.connectToServer calls. While playing around with the code it was relatively easy to add this in the implementation with simple consideration of http.proxyHost and Port system properties; replacing host and port values which were obtained from path method parameter and making initial HTTP CONNECT message to the proxy. In this case, do you think we can add proxy support here? I was thinking how to provide some kind of automation test as well, but no luck so far. Personally I dislike the global nature system properties for configuration unless they are absolutely the only option. Since the WebSocket API has no way of setting a proxy at the moment, system properties might be the only choice :( This is an issue you should raise with the WebSocket EG group. I suggest opening a Jira to request proxy support in a future version. https://java.net/jira/browse/WEBSOCKET_SPEC Here is the issue: https://java.net/jira/browse/WEBSOCKET_SPEC-202 2. So when I got my proxy tunneling in place (with the CONNECT http request) I hit a tougher problem with SSL handshake implementation in WebSocketSslHandshakeThread. The SSL handshake was successful while I was stepping with the debugger through the code and failed when I run the test. It should be some timing issue. This bit needs more debugging. Have you seen this before? No, but the SSL support for WebSocket clients hasn't been heavily used yet so there could still be some bugs to iron out. If you haven't already, take a look at TestWsWebSocketContainer.testConnectToServerEndpointSSL() Mark Thanks. I'll take a look at it. Doing some debugging in the implementation of AsyncChannelWeapperSecure.WebSocketSslHandshakeThread run() revealed that by having small timeout (thread sleep) in NEED_WRAP case, allows SSL handshake to complete successfully. (This is still the case when there is a HTTP Proxy tunnel established between Endpoints) This is not the solution for the problem, of course. Here I attach some sysout logs with working and non-working flows. 1. working example: after sending initial message sleep the executing thread in need_wrap case for little and you get following sequence write: 154 write done: true NEED_UNWRAP read: 2357 read done: true SSL Handshake is OK 2. non working example write: 154 write done: true NEED_UNWRAP read: 1460 much less bytes to consider read done: true ... Exception Any comments? getting closer as the error condition is caused by BUFFER_UNDERFLOW state. Will try to read again in this condition. Basically there is no enough bytes to construct the message in SSLEngine. OK that does the trick. Here is a bug on the issue https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 I'll try to polish a bit and send a small code snippet solving BUFFER_UNDERFLOW case for discussion. cheers Niki Here are two patches for http proxy support (WsWebSocketContainer) and buffer underflow (AsyncChannelWrapperSecure) fix respectively. I'd like to ask for your comments. Patches should be posted to Bugzilla. The mailing list server strips attachments (unless they have proper mime-type, etc. etc.) Thanks: buffer underflow https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 http proxy https://issues.apache.org/bugzilla/show_bug.cgi?id=55006 cheers Niki - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 48358] JSP-unloading reloaded
On 22/05/2013 10:47, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 vivekpandyan vivekpandya...@gmail.com changed: This idiot has been blocked from BZ. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54984] multipart/form-data is not always read with correct encoding
https://issues.apache.org/bugzilla/show_bug.cgi?id=54984 --- Comment #2 from Per Holmberg holmi...@gmail.com --- Created attachment 30311 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30311action=edit Multipart demo war -- 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 54984] multipart/form-data is not always read with correct encoding
https://issues.apache.org/bugzilla/show_bug.cgi?id=54984 --- Comment #3 from Per Holmberg holmi...@gmail.com --- Created attachment 30312 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30312action=edit Multipart demo source -- 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 54999] JSESSIONIDSSO not re-created upon re-authentication on the same request - logout() and login(username,password)
https://issues.apache.org/bugzilla/show_bug.cgi?id=54999 --- Comment #1 from Keith Mashinter kmash...@yahoo.com --- Created attachment 30313 -- https://issues.apache.org/bugzilla/attachment.cgi?id=30313action=edit Fix for Bug 54999 to ensure JSESSIONIDSSO can be re-created In the Bug comments I chose to @override the AuthenticatorBase logout(Request) but the more self-consistent place to patch this seems to be in AuthenticatorBase.register(Request,...) that I've done here against the tc7.0.x/trunk/tc7.0.x/java/org/apache/catalina/authenticator/AuthenticatorBase.java. -- 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 54997] SSL Handshake implementation in AsycnChannelWrapperSecure does not handle SSLEngineResult.Status.BUFFER_UNDERFLOW and SSLEngineResult.Status.BUFFER_OVERFLOW states
https://issues.apache.org/bugzilla/show_bug.cgi?id=54997 Violeta Georgieva violet...@apache.org changed: What|Removed |Added Attachment #30309|0 |1 is patch|| Attachment #30309|application/octet-stream|text/plain mime 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
Re: Automatic deployment changes
Mark, On 5/17/13 3:04 PM, Mark Thomas wrote: On 16/05/2013 21:50, Mark Thomas wrote: The final (for now) changes are: 1. unpackWARs now applies to external WARs as well as WARs located in the Host's appBase. 2. If a WAR is modified (located in the Host's appBase or externally) and there is a context.xml file present in the Host's configBase (which there must be for external WARs) then Tomcat now reloads the web application rather than redeploys it as the Context configuration (defined in the context.xml file in the Host's configBase) hasn't changed. 3. A warning is generate if a DIR in the appBase is ignored because there is a matching WAR and unpackWARs==false. +1 4. Adding an XML or WAR when just a DIR exists will trigger a redeploy. If a WAR is added and unpackWARs==true, the DIR will be replaced. 5. If a WAR or DIR is added to an XML, a reload will occur and the failed context will start serving content provided by the WAR/DIR. When you say added, do you mean a WAR or DIR that exists in the place where the XML pointed (but was previously impossible to deploy, because of the missing WAR/DIR)? -chris signature.asc Description: OpenPGP digital signature
Re: Automatic deployment changes
Mark, On 5/17/13 3:25 PM, Mark Thomas wrote: On 17/05/2013 20:22, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Automatic deployment changes 3. A warning is generate if a DIR in the appBase is ignored because there is a matching WAR and unpackWARs==false. The doc at [1] contains this statement: Note: After deployment, if both a WAR and a DIR are present, Tomcat always serves content from the DIR for performance. Does the always apply even if your point 3 above occurs? The scenario I'm thinking of is: No. It should say After deployment, if a DIR has been created by expanding a WAR then Tomcat always serves content from the DIR for performance. 1. unpackWARs initially true 2. WAR and DIR exist in appBase 3. stop Tomcat 4. change unpackWARs to false 5. modify either WAR or DIR content, but not both 6. restart Tomcat In this case the content will come from the WAR. ... and a warning will be issued, no? -chris signature.asc Description: OpenPGP digital signature
Re: Automatic deployment changes
On 22/05/2013 17:48, Christopher Schultz wrote: Mark, On 5/17/13 3:04 PM, Mark Thomas wrote: 4. Adding an XML or WAR when just a DIR exists will trigger a redeploy. If a WAR is added and unpackWARs==true, the DIR will be replaced. 5. If a WAR or DIR is added to an XML, a reload will occur and the failed context will start serving content provided by the WAR/DIR. When you say added, do you mean a WAR or DIR that exists in the place where the XML pointed (but was previously impossible to deploy, because of the missing WAR/DIR)? Correct. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Automatic deployment changes
On 22/05/2013 17:50, Christopher Schultz wrote: Mark, On 5/17/13 3:25 PM, Mark Thomas wrote: On 17/05/2013 20:22, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Automatic deployment changes 3. A warning is generate if a DIR in the appBase is ignored because there is a matching WAR and unpackWARs==false. The doc at [1] contains this statement: Note: After deployment, if both a WAR and a DIR are present, Tomcat always serves content from the DIR for performance. Does the always apply even if your point 3 above occurs? The scenario I'm thinking of is: No. It should say After deployment, if a DIR has been created by expanding a WAR then Tomcat always serves content from the DIR for performance. 1. unpackWARs initially true 2. WAR and DIR exist in appBase 3. stop Tomcat 4. change unpackWARs to false 5. modify either WAR or DIR content, but not both 6. restart Tomcat In this case the content will come from the WAR. ... and a warning will be issued, no? It should be be, yes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485458 - /tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Author: markt
Date: Wed May 22 22:03:11 2013
New Revision: 1485458
URL: http://svn.apache.org/r1485458
Log:
Cleaner handling of errors
Session may have been closed after an error so get the latch before it closes.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java?rev=1485458r1=1485457r2=1485458view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Wed May 22 22:03:11 2013
@@ -35,19 +35,19 @@ public class TesterSingleMessageClient {
public static class TesterProgrammaticEndpoint extends Endpoint {
+private CountDownLatch latch = null;
+
@Override
public void onClose(Session session, CloseReason closeReason) {
-clearLatch(session);
+clearLatch();
}
@Override
public void onError(Session session, Throwable throwable) {
-clearLatch(session);
+clearLatch();
}
-private void clearLatch(Session session) {
-CountDownLatch latch =
-(CountDownLatch) session.getUserProperties().get(latch);
+private void clearLatch() {
if (latch != null) {
while (latch.getCount() 0) {
latch.countDown();
@@ -57,27 +57,26 @@ public class TesterSingleMessageClient {
@Override
public void onOpen(Session session, EndpointConfig config) {
-// NO-OP
+latch = (CountDownLatch) session.getUserProperties().get(latch);
}
}
@ClientEndpoint
public static class TesterAnnotatedEndpoint {
+private CountDownLatch latch = null;
+
@OnClose
-public void onClose(Session session) {
-clearLatch(session);
+public void onClose() {
+clearLatch();
}
@OnError
-public void onError(Session session,
-@SuppressWarnings(unused) Throwable throwable) {
-clearLatch(session);
+public void onError(@SuppressWarnings(unused) Throwable throwable) {
+clearLatch();
}
-private void clearLatch(Session session) {
-CountDownLatch latch =
-(CountDownLatch) session.getUserProperties().get(latch);
+private void clearLatch() {
if (latch != null) {
while (latch.getCount() 0) {
latch.countDown();
@@ -86,8 +85,8 @@ public class TesterSingleMessageClient {
}
@OnOpen
-public void onOpen() {
-// NO-OP
+public void onOpen(Session session) {
+latch = (CountDownLatch) session.getUserProperties().get(latch);
}
}
-
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-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/4358 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1485458 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
svn commit: r1485489 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Wed May 22 23:11:47 2013
New Revision: 1485489
URL: http://svn.apache.org/r1485489
Log:
Revert r1485458. Right idea but that isn't how to do it.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
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=1485489r1=1485488r2=1485489view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed May 22
23:11:47 2013
@@ -1602,12 +1602,14 @@ public class AprEndpoint extends Abstrac
log.debug(Poller run() adding socket: +
info.socket);
}
-removeFromPoller(info.socket);
timeouts.remove(info.socket);
if (info.read() || info.write()) {
AprSocketWrapper wrapper = connections.get(
Long.valueOf(info.socket));
boolean comet = wrapper.isComet();
+if (comet || wrapper.pollerFlags != 0) {
+removeFromPoller(info.socket);
+}
wrapper.pollerFlags = wrapper.pollerFlags |
(info.read() ? Poll.APR_POLLIN : 0) |
(info.write() ? Poll.APR_POLLOUT : 0);
@@ -1649,6 +1651,11 @@ public class AprEndpoint extends Abstrac
pollerSpace[i] += rv;
connectionCount -= rv;
for (int n = 0; n rv; n++) {
+if (log.isDebugEnabled()) {
+log.debug(Poller run() poll() of socket
+
+desc[n*2+1] + with flags +
+desc[n*2]);
+}
timeouts.remove(desc[n*2+1]);
AprSocketWrapper wrapper = connections.get(
Long.valueOf(desc[n*2+1]));
@@ -1665,7 +1672,7 @@ public class AprEndpoint extends Abstrac
}
} else if ((desc[n*2] Poll.APR_POLLIN)
== Poll.APR_POLLIN) {
if (wrapper.pollerFlags != 0) {
-add(desc[n*2+1], 1,
wrapper.pollerFlags);
+add(desc[n*2+1], 0,
wrapper.pollerFlags);
}
if (!processSocket(desc[n*2+1],
SocketStatus.OPEN_READ)) {
// Close socket and clear pool
@@ -1673,7 +1680,7 @@ public class AprEndpoint extends Abstrac
}
} else if ((desc[n*2] Poll.APR_POLLOUT)
== Poll.APR_POLLOUT) {
if (wrapper.pollerFlags != 0) {
-add(desc[n*2+1], 1,
wrapper.pollerFlags);
+add(desc[n*2+1], 0,
wrapper.pollerFlags);
}
if (!processSocket(desc[n*2+1],
SocketStatus.OPEN_WRITE)) {
// Close socket and clear pool
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485490 - /tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Author: markt
Date: Wed May 22 23:12:14 2013
New Revision: 1485490
URL: http://svn.apache.org/r1485490
Log:
Revert r1485458. Right idea but that isn't how to do it.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java?rev=1485490r1=1485489r2=1485490view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Wed May 22 23:12:14 2013
@@ -35,19 +35,19 @@ public class TesterSingleMessageClient {
public static class TesterProgrammaticEndpoint extends Endpoint {
-private CountDownLatch latch = null;
-
@Override
public void onClose(Session session, CloseReason closeReason) {
-clearLatch();
+clearLatch(session);
}
@Override
public void onError(Session session, Throwable throwable) {
-clearLatch();
+clearLatch(session);
}
-private void clearLatch() {
+private void clearLatch(Session session) {
+CountDownLatch latch =
+(CountDownLatch) session.getUserProperties().get(latch);
if (latch != null) {
while (latch.getCount() 0) {
latch.countDown();
@@ -57,26 +57,27 @@ public class TesterSingleMessageClient {
@Override
public void onOpen(Session session, EndpointConfig config) {
-latch = (CountDownLatch) session.getUserProperties().get(latch);
+// NO-OP
}
}
@ClientEndpoint
public static class TesterAnnotatedEndpoint {
-private CountDownLatch latch = null;
-
@OnClose
-public void onClose() {
-clearLatch();
+public void onClose(Session session) {
+clearLatch(session);
}
@OnError
-public void onError(@SuppressWarnings(unused) Throwable throwable) {
-clearLatch();
+public void onError(Session session,
+@SuppressWarnings(unused) Throwable throwable) {
+clearLatch(session);
}
-private void clearLatch() {
+private void clearLatch(Session session) {
+CountDownLatch latch =
+(CountDownLatch) session.getUserProperties().get(latch);
if (latch != null) {
while (latch.getCount() 0) {
latch.countDown();
@@ -85,8 +86,8 @@ public class TesterSingleMessageClient {
}
@OnOpen
-public void onOpen(Session session) {
-latch = (CountDownLatch) session.getUserProperties().get(latch);
+public void onOpen() {
+// NO-OP
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485495 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Wed May 22 23:13:56 2013
New Revision: 1485495
URL: http://svn.apache.org/r1485495
Log:
Revert r1485489 - wrong file commited
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
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=1485495r1=1485494r2=1485495view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed May 22
23:13:56 2013
@@ -1602,14 +1602,12 @@ public class AprEndpoint extends Abstrac
log.debug(Poller run() adding socket: +
info.socket);
}
+removeFromPoller(info.socket);
timeouts.remove(info.socket);
if (info.read() || info.write()) {
AprSocketWrapper wrapper = connections.get(
Long.valueOf(info.socket));
boolean comet = wrapper.isComet();
-if (comet || wrapper.pollerFlags != 0) {
-removeFromPoller(info.socket);
-}
wrapper.pollerFlags = wrapper.pollerFlags |
(info.read() ? Poll.APR_POLLIN : 0) |
(info.write() ? Poll.APR_POLLOUT : 0);
@@ -1651,11 +1649,6 @@ public class AprEndpoint extends Abstrac
pollerSpace[i] += rv;
connectionCount -= rv;
for (int n = 0; n rv; n++) {
-if (log.isDebugEnabled()) {
-log.debug(Poller run() poll() of socket
+
-desc[n*2+1] + with flags +
-desc[n*2]);
-}
timeouts.remove(desc[n*2+1]);
AprSocketWrapper wrapper = connections.get(
Long.valueOf(desc[n*2+1]));
@@ -1672,7 +1665,7 @@ public class AprEndpoint extends Abstrac
}
} else if ((desc[n*2] Poll.APR_POLLIN)
== Poll.APR_POLLIN) {
if (wrapper.pollerFlags != 0) {
-add(desc[n*2+1], 0,
wrapper.pollerFlags);
+add(desc[n*2+1], 1,
wrapper.pollerFlags);
}
if (!processSocket(desc[n*2+1],
SocketStatus.OPEN_READ)) {
// Close socket and clear pool
@@ -1680,7 +1673,7 @@ public class AprEndpoint extends Abstrac
}
} else if ((desc[n*2] Poll.APR_POLLOUT)
== Poll.APR_POLLOUT) {
if (wrapper.pollerFlags != 0) {
-add(desc[n*2+1], 0,
wrapper.pollerFlags);
+add(desc[n*2+1], 1,
wrapper.pollerFlags);
}
if (!processSocket(desc[n*2+1],
SocketStatus.OPEN_WRITE)) {
// Close socket and clear pool
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1485512 - in /tomcat/trunk/test/org/apache/tomcat/websocket: TestWsRemoteEndpoint.java TestWsWebSocketContainer.java TesterSingleMessageClient.java
Author: markt
Date: Wed May 22 23:52:28 2013
New Revision: 1485512
URL: http://svn.apache.org/r1485512
Log:
Refactor passing of the latch to improve robustness on test failure. Once the
session is closed, user properties are no longer accessible.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsRemoteEndpoint.java
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsRemoteEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TestWsRemoteEndpoint.java?rev=1485512r1=1485511r2=1485512view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/websocket/TestWsRemoteEndpoint.java
(original)
+++ tomcat/trunk/test/org/apache/tomcat/websocket/TestWsRemoteEndpoint.java Wed
May 22 23:52:28 2013
@@ -38,6 +38,7 @@ import org.apache.catalina.startup.Tomca
import org.apache.tomcat.websocket.TesterSingleMessageClient.AsyncHandler;
import org.apache.tomcat.websocket.TesterSingleMessageClient.AsyncText;
import
org.apache.tomcat.websocket.TesterSingleMessageClient.TesterAnnotatedEndpoint;
+import org.apache.tomcat.websocket.TesterSingleMessageClient.TesterEndpoint;
import
org.apache.tomcat.websocket.TesterSingleMessageClient.TesterProgrammaticEndpoint;
public class TestWsRemoteEndpoint extends TomcatBaseTest {
@@ -92,7 +93,9 @@ public class TestWsRemoteEndpoint extend
}
CountDownLatch latch = new CountDownLatch(1);
-wsSession.getUserProperties().put(latch, latch);
+TesterEndpoint tep =
+(TesterEndpoint) wsSession.getUserProperties().get(endpoint);
+tep.setLatch(latch);
AsyncHandler? handler = new AsyncText(latch);
wsSession.addMessageHandler(handler);
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java?rev=1485512r1=1485511r2=1485512view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
(original)
+++ tomcat/trunk/test/org/apache/tomcat/websocket/TestWsWebSocketContainer.java
Wed May 22 23:52:28 2013
@@ -52,6 +52,7 @@ import org.apache.tomcat.util.net.Tester
import org.apache.tomcat.websocket.TesterSingleMessageClient.BasicBinary;
import org.apache.tomcat.websocket.TesterSingleMessageClient.BasicHandler;
import org.apache.tomcat.websocket.TesterSingleMessageClient.BasicText;
+import org.apache.tomcat.websocket.TesterSingleMessageClient.TesterEndpoint;
import
org.apache.tomcat.websocket.TesterSingleMessageClient.TesterProgrammaticEndpoint;
import org.apache.tomcat.websocket.server.Constants;
import org.apache.tomcat.websocket.server.WsListener;
@@ -235,7 +236,9 @@ public class TestWsWebSocketContainer ex
TesterEchoServer.Config.PATH_BASIC));
BasicHandler? handler;
CountDownLatch latch = new CountDownLatch(1);
-wsSession.getUserProperties().put(latch, latch);
+TesterEndpoint tep =
+(TesterEndpoint) wsSession.getUserProperties().get(endpoint);
+tep.setLatch(latch);
if (isTextMessage) {
handler = new BasicText(latch);
} else {
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java?rev=1485512r1=1485511r2=1485512view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/websocket/TesterSingleMessageClient.java
Wed May 22 23:52:28 2013
@@ -33,21 +33,31 @@ import javax.websocket.Session;
public class TesterSingleMessageClient {
-public static class TesterProgrammaticEndpoint extends Endpoint {
+public interface TesterEndpoint {
+void setLatch(CountDownLatch latch);
+}
+
+public static class TesterProgrammaticEndpoint
+extends Endpoint implements TesterEndpoint {
+
+private CountDownLatch latch = null;
+
+@Override
+public void setLatch(CountDownLatch latch) {
+this.latch = latch;
+}
@Override
public void onClose(Session session, CloseReason closeReason) {
-clearLatch(session);
+clearLatch();
}
@Override
public void onError(Session session, Throwable throwable) {
-clearLatch(session);
+clearLatch();
}
-private void clearLatch(Session session) {
-
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/4359 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1485495 Blamelist: markt Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/4360 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1485512 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
