jndi schema is still used in Tomcat 8
Hi, During an investigation of an issue I found that org.apache.jasper.compiler.JspRuntimeContext (rows 513, 517) and org.apache.tomcat.util.scan.StandardJarScanner (row 309) still use jndi schema. Shouldn't it be war schema instead of jndi? Thanks, Violeta
Re: jndi schema is still used in Tomcat 8
On 02/12/2014 08:22, Violeta Georgieva wrote: Hi, During an investigation of an issue I found that org.apache.jasper.compiler.JspRuntimeContext (rows 513, 517) and org.apache.tomcat.util.scan.StandardJarScanner (row 309) still use jndi schema. Shouldn't it be war schema instead of jndi? It certainly shouldn't be JNDI. Whether it needs special handling for WAR would need some testing but I would not be surprised if that were the case. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
On 01/12/2014 21:52, Rémy Maucherat wrote: 2014-12-01 22:00 GMT+01:00 Mark Thomas ma...@apache.org: This is an improvement since it is not just the scheme, host and port but it still reflects the connection being made to WebSocket rather than the Origin of the request. I don't see how the WebSocketContainer can possibly determine what the origin is. It has to rely on a user provided value. Also, I don't see anything in either RFC6455 or the Java WebSocket specification that says that the origin header is mandatory. The user has the opportunity to set its origin header, but having an origin seems mandatory enough to me right now. What is the basis for stating that the origin header is mandatory? If it is a specification then please provide a reference. If it is deduced from the behaviour of the TCK then any test making such an assumption is, in my view, invalid and needs to be challenged. My reasoning for this is as follows: - I am not aware of any requirement to provide an origin header in RFC 6455. - I am not aware of any requirement to provide an origin header in the Java WebSocket specification version 1.0 or 1.1. - The client library has no way to determine what the correct origin header may be. - There are many use cases - e.g. stand-alone Java application - where an origin header makes no sense. Anything you don't like can be wrapped inside the strict flag. This isn't an appropriate place to use the strict flag. This isn't the result of a strict reading of the specification requiring a feature that most users will never need that has a negative impact (e.g. on performance). This is something that that is just plain wrong [1] and should not be in the code in any form. Assuming that this is coming from testing with the TCK, I'd like to see the results of challenging the affected tests (ideally with the discussion on the EG as a result of that challenge) before making any final decision on what the behaviour should be regarding the creation of a default origin header. Mark [1] Show me a specification reference that requires this and I'll happily change my position. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
2014-12-02 9:46 GMT+01:00 Mark Thomas ma...@apache.org: Assuming that this is coming from testing with the TCK, I'd like to see the results of challenging the affected tests (ideally with the discussion on the EG as a result of that challenge) before making any final decision on what the behaviour should be regarding the creation of a default origin header. No, of course it is not a TCK test, I made it up myself. That was funny :) So the assertion is that the TCK indeed seems to require a default origin header. Websockets spec docs seems to indicate the origin header is part of the standard, so that's probably why these tests were added: http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake My opnion: it is more consistent and since the client does it, it doesn't have a very large cost. Thus, I'm not very motivated to bring it to the EG, but you can do it since the issue is simple to describe. Rémy
Re: svn commit: r1642360 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Constants.java LocalStrings.properties TransformationFactory.java WsWebSocketContainer.java server/UpgradeUtil.java server
On 01/12/2014 12:34, Rémy Maucherat wrote: 2014-12-01 11:19 GMT+01:00 Mark Thomas ma...@apache.org: On 28/11/2014 20:33, r...@apache.org wrote: Author: remm Date: Fri Nov 28 20:33:20 2014 New Revision: 1642360 URL: http://svn.apache.org/r1642360 Log: - Use the extensions specified by the configuration (and ignore if there are no associated transformations). I can see how this would make sense if there was a way for the application to configure its own extensions but there isn't. At the moment extensions have to be hard-coded into the container and there is no requirement to support any extension. If a server endpoint requests an unsupported extension then shouldn't that trigger some sort of error? The tests use extensions (to see if it's supported). They are declared and of course they do nothing special, but it is supposed to be usable. To enable some, it uses a ServerEndpointConfig that overrides getExtensions, declared using a ServerApplicationConfig. Creativity :) Basically, if you give these guys some APIs that are placeholders but are user accessible they'll try to test them anyway. I can see where this test is coming from but disabling the check that a valid extension is being requested just to pass the test is the wrong thing to do - particularly given your next comment. Actually, the test is bad since having a builtin extension breaks it (it just matches the header), but I ignored that part after verifying it. OK. That test needs to be challenged as well then. I see two issues from this thread: - The test requires the server to support arbitrary extensions which prevents the server from throwing an exception and preventing deployment when a server endpoint requests an unsupported extension. - The test does not expect the server to support any other extensions and it is likely that implementations will support at some. I'm not sure the best way of handling the first point. I can see the need to test the API but it is more important to me that configuration / coding errors that request an unsupported extension are reported early. Possible options: a) Require servers to support a NO-OP extension. Kind of pointless since it would just be there to pass the tests. b) Drop the test. Not ideal. If the API is there it should be tested. c) Add a ignore unknown extensions flag we use just for running the tests. d) Require compression support and then use that to test the API. e) Add support for application provided extensions and then use that to test the API. c) for now followed by e) is probably the best solution with c) being removed once e) was in place. snip/ - Add path params as params too. I don't see that discussed anywhere in the WebSocket spec. I went back through the EG discussions and the thread that I think led up to this [1],[2] was very clear that this was the query parameters and did not include the path parameters [1] https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2012-07/message/2 [2] http://markmail.org/message/qqwqcyg4npxv3bks Yes, I cannot find any mention of that, but the tests are quite explicit and they use both the query parameters and the path parameters names from that PathParam annotation. IMO it is not useless, users could maybe have asked for that. Moar creativity :) I agree it has some uses. I think this also needs raising with the EG for clarification. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57287] Sort files listed by DefaultServlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=57287 --- Comment #6 from Oleg Trokhov otro...@minsk.ximxim.com --- Created attachment 32249 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32249action=edit sorting list I refactor import, so checkstyle task passed. So we leave my parameter naming or rename as as Apache HTTPD? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
On 02/12/2014 09:01, Rémy Maucherat wrote: 2014-12-02 9:46 GMT+01:00 Mark Thomas ma...@apache.org: Assuming that this is coming from testing with the TCK, I'd like to see the results of challenging the affected tests (ideally with the discussion on the EG as a result of that challenge) before making any final decision on what the behaviour should be regarding the creation of a default origin header. No, of course it is not a TCK test, I made it up myself. That was funny :) So the assertion is that the TCK indeed seems to require a default origin header. Websockets spec docs seems to indicate the origin header is part of the standard, so that's probably why these tests were added: http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake Wikipedia does not define the WebSocket standard. That is defined in RFC 6455. To quote from RFC 6455: quote The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser. The server is informed of the script origin generating the WebSocket connection request. If the server does not wish to accept connections from this origin, it can choose to reject the connection by sending an appropriate HTTP error code. This header field is sent by browser clients; for non-browser clients, this header field may be sent if it makes sense in the context of those clients. /quote Note may be sent. The origin header is not mandatory so the TCK is wrong and needs to be challenged. I can't do that since I don't have access to the TCK. You have access to the TCK, you have to challenge it. If the TCK wants to test origin filtering then it simply needs to set the origin header in the TCK client code. My opnion: it is more consistent and since the client does it, it doesn't have a very large cost. Thus, I'm not very motivated to bring it to the EG, but you can do it since the issue is simple to describe. My opinion is that the default value currently being provided is just plain wrong. The origin is meant to be the script origin generating the WebSocket connection request not the scheme, host and port of the WebSocket connection currently being made. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
2014-12-02 10:12 GMT+01:00 Mark Thomas ma...@apache.org:My opinion is that the default value currently being provided is just plain wrong. The origin is meant to be the script origin generating the WebSocket connection request not the scheme, host and port of the WebSocket connection currently being made. Well, I think we covered the topic then. I am not going to challenge the TCK [there could be more problematic issues like batch mode flushing or general output, so there's no way I'll do that for a trivial item]. If this is important for you, you should veto this and I'll remove it. Rémy
Re: svn commit: r1642360 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Constants.java LocalStrings.properties TransformationFactory.java WsWebSocketContainer.java server/UpgradeUtil.java server
2014-12-02 10:04 GMT+01:00 Mark Thomas ma...@apache.org: Possible options: a) Require servers to support a NO-OP extension. Kind of pointless since it would just be there to pass the tests. b) Drop the test. Not ideal. If the API is there it should be tested. c) Add a ignore unknown extensions flag we use just for running the tests. d) Require compression support and then use that to test the API. e) Add support for application provided extensions and then use that to test the API. c) for now followed by e) is probably the best solution with c) being removed once e) was in place. What is the best option for the websockets implementation configuration options ? Rémy
[Bug 57215] Regression in Tomcat 7.0.54 after Bug 56501 with urls starting with //
https://issues.apache.org/bugzilla/show_bug.cgi?id=57215 --- Comment #8 from Konstantin Kolinko knst.koli...@gmail.com --- (In reply to Konstantin Kolinko from comment #5) 5. In CoyoteAdapter.postParseRequest() when decodedURI.getType() is not bytes (e.g. when requestURI is changed by RewriteValve), normalization is skipped. I think that it should not be skipped. Skipping url-decoding step is also wrong. If RewriteValve provides a non-encoded requestUri, it means that there is a bug in RewriteValve. Web Application should assume that requestURI needs url-decoding. It cannot find out that url-decoding shall be skipped. Implementation of Request.getContextPath() in r1640083/r1642766 is an example of a victim of this bug. It always performs url-decoding. 3. In unexpected situations, error out (400) instead of falling through. 3 makes sense if we do 2 but I don't think 2 is the way to go. I do not like that Request.getContextPath() falls through to returning requestUri. It may result in security issues. -- 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: jndi schema is still used in Tomcat 8
2014-12-02 10:44 GMT+02:00 Mark Thomas ma...@apache.org: On 02/12/2014 08:22, Violeta Georgieva wrote: Hi, During an investigation of an issue I found that org.apache.jasper.compiler.JspRuntimeContext (rows 513, 517) and org.apache.tomcat.util.scan.StandardJarScanner (row 309) still use jndi schema. Shouldn't it be war schema instead of jndi? It certainly shouldn't be JNDI. Whether it needs special handling for WAR would need some testing but I would not be surprised if that were the case. Thanks I'll check that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
2014-12-02 12:12 GMT+03:00 Mark Thomas ma...@apache.org: On 02/12/2014 09:01, Rémy Maucherat wrote: 2014-12-02 9:46 GMT+01:00 Mark Thomas ma...@apache.org: Assuming that this is coming from testing with the TCK, I'd like to see the results of challenging the affected tests (ideally with the discussion on the EG as a result of that challenge) before making any final decision on what the behaviour should be regarding the creation of a default origin header. No, of course it is not a TCK test, I made it up myself. That was funny :) So the assertion is that the TCK indeed seems to require a default origin header. Websockets spec docs seems to indicate the origin header is part of the standard, so that's probably why these tests were added: http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake Wikipedia does not define the WebSocket standard. That is defined in RFC 6455. To quote from RFC 6455: quote The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser. The server is informed of the script origin generating the WebSocket connection request. If the server does not wish to accept connections from this origin, it can choose to reject the connection by sending an appropriate HTTP error code. This header field is sent by browser clients; for non-browser clients, this header field may be sent if it makes sense in the context of those clients. /quote Note may be sent. The origin header is not mandatory so the TCK is wrong and needs to be challenged. I can't do that since I don't have access to the TCK. You have access to the TCK, you have to challenge it. If the TCK wants to test origin filtering then it simply needs to set the origin header in the TCK client code. Just some thoughts (not knowing what TCK does here): Per WebSocket RFC the origin header is mandatory for browser clients and not mandatory for non-browser clients. If one implements a web application then it is reasonable to expect that client is a web browser. If Origin is unknown, it can be written as null (a string of 4 characters) https://tools.ietf.org/html/rfc6454#section-6.1 Origin RFC 7.3.: [quote] Whenever a user agent issues an HTTP request from a privacy- sensitive context, the user agent MUST send the value null in the Origin header field. [/quote] If one runs a command-line websocket client instead of a browser, can it be configured to send a specific value of Origin header? (Via command line or via a system property) My opnion: it is more consistent and since the client does it, it doesn't have a very large cost. Thus, I'm not very motivated to bring it to the EG, but you can do it since the issue is simple to describe. My opinion is that the default value currently being provided is just plain wrong. The origin is meant to be the script origin generating the WebSocket connection request not the scheme, host and port of the WebSocket connection currently being made. Agreed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1642845 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
Author: remm
Date: Tue Dec 2 11:56:59 2014
New Revision: 1642845
URL: http://svn.apache.org/r1642845
Log:
Remove origin header due to bad feedback.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1642845r1=1642844r2=1642845view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Tue
Dec 2 11:56:59 2014
@@ -242,18 +242,6 @@ public class WsWebSocketContainer
sa = new InetSocketAddress(host, port);
}
-// Origin header
-if (!reqHeaders.containsKey(Constants.ORIGIN_HEADER_NAME)) {
-ListString originValues = new ArrayList(1);
-StringBuilder originValue = new StringBuilder();
-
originValue.append(path.getScheme()).append(://).append(path.getHost());
-if (port != -1) {
-originValue.append(':').append(port);
-}
-originValues.add(originValue.toString());
-reqHeaders.put(Constants.ORIGIN_HEADER_NAME, originValues);
-}
-
ByteBuffer request = createRequest(path, reqHeaders);
AsynchronousSocketChannel socketChannel;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56966] AccessLogValve's elapsed time has 15ms precision on Windows
https://issues.apache.org/bugzilla/show_bug.cgi?id=56966 --- Comment #4 from Tom Fitzhenry t...@tom-fitzhenry.me.uk --- The machine is a virtual machine running on the Windows Azure hypervisor (similar to Hyper-V, supposedly). The guest OS runs Windows Server 2012 R2, and reports its hardware as: Processor: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.260GHz 2.20GHz Installed memory (RAM): 14.0 GB System type: 60-bit Operation System, x64-based processor The program on http://stackoverflow.com/questions/7859019/system-currenttimemillis-is-not-accurate-on-windows-xp , when executed against Oracle JRE 7, prints 15ms. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
On 02/12/2014 09:24, Rémy Maucherat wrote: 2014-12-02 10:12 GMT+01:00 Mark Thomas ma...@apache.org:My opinion is that the default value currently being provided is just plain wrong. The origin is meant to be the script origin generating the WebSocket connection request not the scheme, host and port of the WebSocket connection currently being made. Well, I think we covered the topic then. I am not going to challenge the TCK [there could be more problematic issues like batch mode flushing or general output, so there's no way I'll do that for a trivial item]. If this is important for you, you should veto this and I'll remove it. I think there might a solution that works for everybody (thanks Konstantin). What about setting an origin header value of null in the client if none is set by the user? That is consistent with all the specifications and is arguably better than doing nothing which is what we are doing at the moment. Would that be sufficient to address the TCK issue as well? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1642721 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
2014-12-02 15:47 GMT+01:00 Mark Thomas ma...@apache.org: I think there might a solution that works for everybody (thanks Konstantin). What about setting an origin header value of null in the client if none is set by the user? That is consistent with all the specifications and is arguably better than doing nothing which is what we are doing at the moment. Would that be sufficient to address the TCK issue as well? In this situation, it requires 127.0.0.1 to be in the Origin header value. Rémy
[Bug 57252] Custom error page is not used for an error that occurs asynchronously
https://issues.apache.org/bugzilla/show_bug.cgi?id=57252 Mark Thomas ma...@apache.org changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas ma...@apache.org --- FYI. I am currently working on this but my test cases have identified a further concurrency issue with the error handling that I am going to have to fix first. -- 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 54143] Add display of PermGen memory pool usage to the Status page of the Manager webapp
https://issues.apache.org/bugzilla/show_bug.cgi?id=54143 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com --- Created attachment 32252 -- https://issues.apache.org/bugzilla/attachment.cgi?id=32252action=edit 2014-12-02_tc6_54143_v1.patch Patch for Tomcat 6 Add display of memory pools. Update and fix XSL style and schema. Backport of r1409014, r1453106, r1453119, r1348992 from tomcat/tc7.0.x/trunk. add bug54143/bug: Add display of the memory pools usage (including PermGen) to the Status page of the Manager web application. (kkolinko) /add fix Fix several issues with codestatus.xsd/code schema in Manager web application, testing it against actual output of StatusTransformer class. (kkolinko) /fix To test the schema, one can save output of /manager/status?XML=true command and add the following attributes to the root status element: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=status.xsd -- 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: r1642898 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Tue Dec 2 15:18:32 2014 New Revision: 1642898 URL: http://svn.apache.org/r1642898 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=1642898r1=1642897r2=1642898view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Dec 2 15:18:32 2014 @@ -51,6 +51,50 @@ PATCHES PROPOSED TO BACKPORT: +1: schultz, and I withdraw above proposal if this one is accepted -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54143 + 1. Add display of memory pools usage (including PermGen) to the Status page + of the Manager web application. + + 2. Fix several issues with codestatus.xsd/code schema in Manager web + application, testing it against actual output of StatusTransformer + class. Add the new memorypool/ element to the schema. + + To test the schema, one can save output of /manager/status?XML=true command and + add the following attributes to the root status element: + +xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; +xsi:noNamespaceSchemaLocation=status.xsd + + This fixes the following schema issues: + 1) Remove minSpareThreads, maxSpareThreads attributes from schema and XSLT. + + StatusTransformer does not generate them on threadInfo element. + + 2) Correct cardinality of worker/ and connector/ elements. + + There are 0..inf workers, 1..inf connectors. + + (In theory there are 0..inf connectors, but if one can access the manager + app then at least one connector is running) + + 3) Correct misspelled attribute name, recieved-received. + + There are several code paths in StatusTransformer and one generated + misspelled name, while others used the correct one. Fixed the java code + and schema. + + 4) Add the new memorypool/ element to the schema. + + Backport of r1409014, r1453106, r1453119, r1348992 from tomcat/tc7.0.x/trunk. + + Justification: +To be able to monitor PermGen. The necessary APIs (MemoryPoolMXBean) +are available since Java 5. + + https://issues.apache.org/bugzilla/attachment.cgi?id=32252action=edit + +1: kkolinko + -1: + PATCHES/ISSUES THAT ARE STALLED: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1642962 - /tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Author: remm
Date: Tue Dec 2 17:35:04 2014
New Revision: 1642962
URL: http://svn.apache.org/r1642962
Log:
Add failing websockets test.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java?rev=1642962r1=1642961r2=1642962view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Tue Dec 2 17:35:04 2014
@@ -39,6 +39,7 @@ import javax.websocket.Endpoint;
import javax.websocket.EndpointConfig;
import javax.websocket.Extension;
import javax.websocket.MessageHandler;
+import javax.websocket.OnError;
import javax.websocket.OnMessage;
import javax.websocket.Session;
import javax.websocket.WebSocketContainer;
@@ -48,7 +49,6 @@ import javax.websocket.server.ServerEndp
import org.junit.Assert;
import org.junit.Test;
-
import org.apache.catalina.Context;
import org.apache.catalina.servlets.DefaultServlet;
import org.apache.catalina.startup.Tomcat;
@@ -63,6 +63,7 @@ public class TestEncodingDecoding extend
private static final String PATH_PROGRAMMATIC_EP = /echoProgrammaticEP;
private static final String PATH_ANNOTATED_EP = /echoAnnotatedEP;
private static final String PATH_GENERICS_EP = /echoGenericsEP;
+private static final String PATH_MESSAGES_EP = /echoMessagesEP;
@Test
@@ -215,6 +216,61 @@ public class TestEncodingDecoding extend
session.close();
}
+//@Test
+public void testMessagesEndPoints() throws Exception {
+// Set up utility classes
+MessagesServer server = new MessagesServer();
+SingletonConfigurator.setInstance(server);
+ServerConfigListener.setPojoClazz(MessagesServer.class);
+
+Tomcat tomcat = getTomcatInstance();
+// No file system docBase required
+Context ctx = tomcat.addContext(, null);
+ctx.addApplicationListener(ServerConfigListener.class.getName());
+Tomcat.addServlet(ctx, default, new DefaultServlet());
+ctx.addServletMapping(/, default);
+
+WebSocketContainer wsContainer =
+ContainerProvider.getWebSocketContainer();
+
+tomcat.start();
+
+StringClient client = new StringClient();
+URI uri = new URI(ws://localhost: + getPort() + PATH_MESSAGES_EP);
+Session session = wsContainer.connectToServer(client, uri);
+
+session.getBasicRemote().sendText(MESSAGE_ONE);
+
+// Should not take very long
+int i = 0;
+while (i 20) {
+if (server.received.size() 0 client.received.size() 0) {
+break;
+}
+Thread.sleep(100);
+}
+
+// Check messages were received
+Assert.assertEquals(1, server.received.size());
+Assert.assertEquals(1, client.received.size());
+
+// Check correct messages were received
+Assert.assertEquals(MESSAGE_ONE, server.received.peek());
+session.close();
+
+Assert.assertNull(server.t);
+
+// Should not take very long but some failures have been seen
+i = testEvent(MsgStringEncoder.class.getName()+:init, 0);
+i = testEvent(MsgStringDecoder.class.getName()+:init, i);
+i = testEvent(MsgByteEncoder.class.getName()+:init, i);
+i = testEvent(MsgByteDecoder.class.getName()+:init, i);
+i = testEvent(MsgStringEncoder.class.getName()+:destroy, i);
+i = testEvent(MsgStringDecoder.class.getName()+:destroy, i);
+i = testEvent(MsgByteEncoder.class.getName()+:destroy, i);
+i = testEvent(MsgByteDecoder.class.getName()+:destroy, i);
+}
+
private int testEvent(String name, int count) throws InterruptedException {
int i = count;
@@ -260,6 +316,19 @@ public class TestEncodingDecoding extend
}
+@ClientEndpoint
+public static class StringClient {
+
+private QueueObject received = new ConcurrentLinkedQueue();
+
+@OnMessage
+public void rx(String in) {
+received.add(in);
+}
+
+}
+
+
@ServerEndpoint(value=PATH_GENERICS_EP,
decoders={ListStringDecoder.class},
encoders={ListStringEncoder.class},
@@ -278,6 +347,28 @@ public class TestEncodingDecoding extend
}
+@ServerEndpoint(value=PATH_MESSAGES_EP,
+configurator=SingletonConfigurator.class)
+public static class MessagesServer {
+
+private QueueString received = new ConcurrentLinkedQueue();
+private Throwable t = null;
+
+@OnMessage
+public String onMessage(String message, Session session) {
+received.add(message);
+
svn commit: r1642974 - /tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Author: remm
Date: Tue Dec 2 18:09:44 2014
New Revision: 1642974
URL: http://svn.apache.org/r1642974
Log:
Add another websockets failing test on batch mode.
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Modified:
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java?rev=1642974r1=1642973r2=1642974view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
Tue Dec 2 18:09:44 2014
@@ -60,10 +60,12 @@ import org.apache.tomcat.websocket.serve
public class TestEncodingDecoding extends TomcatBaseTest {
private static final String MESSAGE_ONE = message-one;
+private static final String MESSAGE_TWO = message-two;
private static final String PATH_PROGRAMMATIC_EP = /echoProgrammaticEP;
private static final String PATH_ANNOTATED_EP = /echoAnnotatedEP;
private static final String PATH_GENERICS_EP = /echoGenericsEP;
private static final String PATH_MESSAGES_EP = /echoMessagesEP;
+private static final String PATH_BATCHED_EP = /echoBatchedEP;
@Test
@@ -272,6 +274,62 @@ public class TestEncodingDecoding extend
}
+//@Test
+public void testBatchedEndPoints() throws Exception {
+// Set up utility classes
+BatchedServer server = new BatchedServer();
+SingletonConfigurator.setInstance(server);
+ServerConfigListener.setPojoClazz(BatchedServer.class);
+
+Tomcat tomcat = getTomcatInstance();
+// No file system docBase required
+Context ctx = tomcat.addContext(, null);
+ctx.addApplicationListener(ServerConfigListener.class.getName());
+Tomcat.addServlet(ctx, default, new DefaultServlet());
+ctx.addServletMapping(/, default);
+
+WebSocketContainer wsContainer =
+ContainerProvider.getWebSocketContainer();
+
+tomcat.start();
+
+StringClient client = new StringClient();
+URI uri = new URI(ws://localhost: + getPort() + PATH_BATCHED_EP);
+Session session = wsContainer.connectToServer(client, uri);
+
+session.getBasicRemote().sendText(MESSAGE_ONE);
+
+// Should not take very long
+int i = 0;
+while (i++ 20) {
+if (server.received.size() 0 client.received.size() 0) {
+break;
+}
+Thread.sleep(100);
+}
+
+// Check messages were received
+Assert.assertEquals(1, server.received.size());
+Assert.assertEquals(2, client.received.size());
+
+// Check correct messages were received
+Assert.assertEquals(MESSAGE_ONE, server.received.peek());
+session.close();
+
+Assert.assertNull(server.t);
+
+// Should not take very long but some failures have been seen
+i = testEvent(MsgStringEncoder.class.getName()+:init, 0);
+i = testEvent(MsgStringDecoder.class.getName()+:init, i);
+i = testEvent(MsgByteEncoder.class.getName()+:init, i);
+i = testEvent(MsgByteDecoder.class.getName()+:init, i);
+i = testEvent(MsgStringEncoder.class.getName()+:destroy, i);
+i = testEvent(MsgStringDecoder.class.getName()+:destroy, i);
+i = testEvent(MsgByteEncoder.class.getName()+:destroy, i);
+i = testEvent(MsgByteDecoder.class.getName()+:destroy, i);
+}
+
+
private int testEvent(String name, int count) throws InterruptedException {
int i = count;
while (i 50) {
@@ -369,6 +427,28 @@ public class TestEncodingDecoding extend
}
+@ServerEndpoint(value=PATH_BATCHED_EP,
+configurator=SingletonConfigurator.class)
+public static class BatchedServer {
+
+private QueueString received = new ConcurrentLinkedQueue();
+private Throwable t = null;
+
+@OnMessage
+public String onMessage(String message, Session session) throws
IOException {
+received.add(message);
+session.getAsyncRemote().setBatchingAllowed(true);
+session.getAsyncRemote().sendText(MESSAGE_ONE);
+return MESSAGE_TWO;
+}
+
+@OnError
+public void onError(Session session, Throwable t) throws IOException {
+t.printStackTrace();
+this.t = t;
+}
+}
+
@ServerEndpoint(value=PATH_ANNOTATED_EP,
decoders={MsgStringDecoder.class, MsgByteDecoder.class},
encoders={MsgStringEncoder.class, MsgByteEncoder.class},
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Catching up
Guys, For a myriad of personal, professional, and health reasons, I've been out of pocket for many months. I'm finally starting to catch up today on 9200 Tomcat developer and user list messages. It will take me many days. I just wanted to let y'all know that I'm still alive, and head off any where have you been, bro? responses to any responses I may send in the coming days. Glad to be back! Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Drop comet support in Tomcat 9 onwards
On Jun 19, 2014, at 10:45 AM, Rémy Maucherat wrote: 2014-06-18 23:40 GMT+02:00 Mark Thomas ma...@apache.org: I have been thinking about connector refactoring for Tomcat 9. Currently BIO is planned to be dropped due to the number of features in the servlet spec that rely on non-blocking IO. I would like to propose dropping support for Comet in Tomcat 9 onwards. The reasons are: - WebSocket is already far more popular (based on question volume on the users list) - Comet support adds a fair amount of complexity to the connector code Thoughts? Keep in mind that 8.0.x isn't stable yet and any 9.0.x is likely to be several years away. Yes, of course, that API is only a precursor to Servlet 3.1, and is now fully replaced. Most likely existing code can be ported over to Servlet 3.1 rather easily. Rémy +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1643002 - /tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Author: markt
Date: Tue Dec 2 20:16:01 2014
New Revision: 1643002
URL: http://svn.apache.org/r1643002
Log:
Fix concurrency issue identified while investigating BZ 57252. Ensure that
non-container threads can't change the async state until the container thread
has completed post-processing.
Modified:
tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
Modified: tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java?rev=1643002r1=1643001r2=1643002view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java [UTF-8]
(original)
+++ tomcat/trunk/java/org/apache/coyote/AsyncStateMachine.java [UTF-8] Tue Dec
2 20:16:01 2014
@@ -106,28 +106,30 @@ public class AsyncStateMachine {
StringManager.getManager(Constants.Package);
private static enum AsyncState {
-DISPATCHED(false, false, false, false),
-STARTING(true, true, false, false),
-STARTED(true, true, false, false),
-MUST_COMPLETE(true, true, true, false),
-COMPLETING(true, false, true, false),
-TIMING_OUT(true, false, false, false),
-MUST_DISPATCH(true, true, false, true),
-DISPATCHING(true, false, false, true),
-READ_WRITE_OP(true, true, false, false),
-ERROR(true, false, false, false);
+DISPATCHED(false, false, false, false, false),
+STARTING(true, true, false, false, true),
+STARTED(true, true, false, false, false),
+MUST_COMPLETE(true, true, true, false, false),
+COMPLETING(true, false, true, false, false),
+TIMING_OUT(true, false, false, false, false),
+MUST_DISPATCH(true, true, false, true, true),
+DISPATCHING(true, false, false, true, false),
+READ_WRITE_OP(true, true, false, false, true),
+ERROR(true, false, false, false, false);
private final boolean isAsync;
private final boolean isStarted;
private final boolean isCompleting;
private final boolean isDispatching;
+private final boolean pauseNonContainerThread;
private AsyncState(boolean isAsync, boolean isStarted, boolean
isCompleting,
-boolean isDispatching) {
+boolean isDispatching, boolean pauseNonContainerThread) {
this.isAsync = isAsync;
this.isStarted = isStarted;
this.isCompleting = isCompleting;
this.isDispatching = isDispatching;
+this.pauseNonContainerThread = pauseNonContainerThread;
}
public boolean isAsync() {
@@ -145,6 +147,10 @@ public class AsyncStateMachine {
public boolean isCompleting() {
return isCompleting;
}
+
+public boolean getPauseNonContainerThread() {
+return pauseNonContainerThread;
+}
}
@@ -211,6 +217,12 @@ public class AsyncStateMachine {
*/
public synchronized SocketState asyncPostProcess() {
+// Unpause any non-container threads that may be waiting for this
+// container thread to complete this method. Note because of the syncs
+// those non-container threads won't start back up until until this
+// method exits.
+notifyAll();
+
if (state == AsyncState.STARTING || state == AsyncState.READ_WRITE_OP)
{
state = AsyncState.STARTED;
return SocketState.LONG;
@@ -241,8 +253,8 @@ public class AsyncStateMachine {
public synchronized boolean asyncComplete() {
+pauseNonContainerThread();
boolean doComplete = false;
-
if (state == AsyncState.STARTING) {
state = AsyncState.MUST_COMPLETE;
} else if (state == AsyncState.STARTED) {
@@ -282,6 +294,7 @@ public class AsyncStateMachine {
public synchronized boolean asyncDispatch() {
+pauseNonContainerThread();
boolean doDispatch = false;
if (state == AsyncState.STARTING) {
state = AsyncState.MUST_DISPATCH;
@@ -377,4 +390,24 @@ public class AsyncStateMachine {
processor.getRequest().listener = null;
processor.getRequest().getResponse().listener = null;
}
+
+
+/*
+ * startAsync() has been called but the container thread where this was
+ * called has not completed processing. To avoid various race conditions -
+ * including several related to error page handling - pause this
+ * non-container thread until the container thread has finished processing.
+ * The non-container thread will be paused until the container thread
+ * completes asyncPostProcess().
+ */
+private synchronized void pauseNonContainerThread() {
+while (!ContainerThreadMarker.isContainerThread()
+state.getPauseNonContainerThread()) {
+try {
+wait();
+
svn commit: r1643007 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
Author: remm
Date: Tue Dec 2 21:15:44 2014
New Revision: 1643007
URL: http://svn.apache.org/r1643007
Log:
As an additional cleanup, don't write any empty message when flushing and
there's no data to flush.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java?rev=1643007r1=1643006r2=1643007view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsRemoteEndpointImplBase.java
Tue Dec 2 21:15:44 2014
@@ -937,7 +937,9 @@ public abstract class WsRemoteEndpointIm
sm.getString(wsRemoteEndpoint.closedOutputStream));
}
-doWrite(false);
+if (buffer.position() 0) {
+doWrite(false);
+}
}
@Override
@@ -1012,7 +1014,9 @@ public abstract class WsRemoteEndpointIm
sm.getString(wsRemoteEndpoint.closedWriter));
}
-doWrite(false);
+if (buffer.position() 0) {
+doWrite(false);
+}
}
@Override
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1643008 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Util.java pojo/PojoMethodMapping.java
Author: remm
Date: Tue Dec 2 21:16:51 2014
New Revision: 1643008
URL: http://svn.apache.org/r1643008
Log:
Websockets annotations can be located on superclasses, and also improve
duplicates detection.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/Util.java
tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
Modified: tomcat/trunk/java/org/apache/tomcat/websocket/Util.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/Util.java?rev=1643008r1=1643007r2=1643008view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/Util.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/Util.java Tue Dec 2 21:16:51
2014
@@ -576,9 +576,10 @@ public class Util {
new ArrayList();
private final ListClass? extends Decoder binaryDecoders =
new ArrayList();
-
+private final Class? target;
public DecoderMatch(Class? target, ListDecoderEntry
decoderEntries) {
+this.target = target;
for (DecoderEntry decoderEntry : decoderEntries) {
if (decoderEntry.getClazz().isAssignableFrom(target)) {
if (Binary.class.isAssignableFrom(
@@ -624,6 +625,11 @@ public class Util {
}
+public Class? getTarget() {
+return target;
+}
+
+
public boolean hasMatches() {
return (textDecoders.size() 0) || (binaryDecoders.size() 0);
}
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java?rev=1643008r1=1643007r2=1643008view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/pojo/PojoMethodMapping.java
Tue Dec 2 21:16:51 2014
@@ -22,6 +22,7 @@ import java.lang.annotation.Annotation;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.nio.ByteBuffer;
+import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
@@ -64,7 +65,7 @@ public class PojoMethodMapping {
private final PojoPathParam[] onOpenParams;
private final PojoPathParam[] onCloseParams;
private final PojoPathParam[] onErrorParams;
-private final SetMessageHandlerInfo onMessage = new HashSet();
+private final ListMessageHandlerInfo onMessage = new ArrayList();
private final String wsPath;
@@ -78,43 +79,56 @@ public class PojoMethodMapping {
Method open = null;
Method close = null;
Method error = null;
-for (Method method : clazzPojo.getDeclaredMethods()) {
-if (method.getAnnotation(OnOpen.class) != null) {
-checkPublic(method);
-if (open == null) {
-open = method;
-} else {
-// Duplicate annotation
-throw new DeploymentException(sm.getString(
-pojoMethodMapping.duplicateAnnotation,
-OnOpen.class, clazzPojo));
-}
-} else if (method.getAnnotation(OnClose.class) != null) {
-checkPublic(method);
-if (close == null) {
-close = method;
-} else {
-// Duplicate annotation
-throw new DeploymentException(sm.getString(
-pojoMethodMapping.duplicateAnnotation,
-OnClose.class, clazzPojo));
-}
-} else if (method.getAnnotation(OnError.class) != null) {
-checkPublic(method);
-if (error == null) {
-error = method;
+Class? currentClazz = clazzPojo;
+while (!currentClazz.equals(Object.class)) {
+for (Method method : currentClazz.getDeclaredMethods()) {
+if (method.getAnnotation(OnOpen.class) != null) {
+checkPublic(method);
+if (open == null) {
+open = method;
+} else {
+// Duplicate annotation
+throw new DeploymentException(sm.getString(
+pojoMethodMapping.duplicateAnnotation,
+OnOpen.class, clazzPojo));
+}
+} else if (method.getAnnotation(OnClose.class) != null) {
+checkPublic(method);
+if (close == null) {
+close = method;
+} else {
+// Duplicate annotation
+
[Bug 57274] Annotation scanning can cause classes to skip class transformation
https://issues.apache.org/bugzilla/show_bug.cgi?id=57274 --- Comment #3 from Nick Williams nicho...@nicholaswilliams.net --- I will think about this some. Off the top of my head, I don't know what the answer is, but it sure would be nice if there were a solution. -- 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: Catching up
Huh. Amazing how fast that went. I'm caught up on everything since May 7 (last time I checked my email in this folder). Good job, everyone involved, on releasing 8.0.x stable, beginning 9.0.x, and addressing many bugs. Kudos! Nick On Dec 2, 2014, at 1:20 PM, Nick Williams wrote: Guys, For a myriad of personal, professional, and health reasons, I've been out of pocket for many months. I'm finally starting to catch up today on 9200 Tomcat developer and user list messages. It will take me many days. I just wanted to let y'all know that I'm still alive, and head off any where have you been, bro? responses to any responses I may send in the coming days. Glad to be back! Nick - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57274] Annotation scanning can cause classes to skip class transformation
https://issues.apache.org/bugzilla/show_bug.cgi?id=57274 --- Comment #4 from Phillip pverhey...@broadleafcommerce.com --- The solution that I had was to completely disable the scanning by adding an empty absolute-ordering / tag into my web.xml. This obviously means that there is no way to have both my Spring/persistent unit class transformation along with the ServletContainerInitializers (not an issue in my case). I believe that one possible solution here would be to disable what I believe to be a performance improvement of loading the classes by the class loader. If the classes were not loaded by the classloader at all and instead every single class was loaded by the FileInputStream, then this would not be a problem at all. Perhaps there could be some sort of startup flag that controls whether or not to use the class loader to look for ServletContainerInitializers or to skip it and load all of them by FileInputStreams? Mark, what do you mean by delay the transformation until the the class is declared? Does this mean moving the transformation code from WebAppClassLoader to after it has retrieved the cache from resourceEntries, but prior to actually loading the class itself (like via a Class.forName())? This seems like a better solution to me. It seems there is a slight deviation by looking up a class by name with a getResourceAsStream() and referencing it by doing a Class.forName(). -- 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 57274] Annotation scanning can cause classes to skip class transformation
https://issues.apache.org/bugzilla/show_bug.cgi?id=57274 --- Comment #5 from Mark Thomas ma...@apache.org --- (In reply to Phillip from comment #4) Mark, what do you mean by delay the transformation until the the class is declared? Does this mean moving the transformation code from WebAppClassLoader to after it has retrieved the cache from resourceEntries, but prior to actually loading the class itself (like via a Class.forName())? Yes. Basically delay the transformation until just before we call defineClass(). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1643008 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Util.java pojo/PojoMethodMapping.java
On 02/12/2014 21:16, r...@apache.org wrote: Author: remm Date: Tue Dec 2 21:16:51 2014 New Revision: 1643008 URL: http://svn.apache.org/r1643008 Log: Websockets annotations can be located on superclasses, and also improve duplicates detection. No they can't. See section 4.8 of the Java WebSocket specification that explicitly states that this is not allowed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Drop comet support in Tomcat 9 onwards
Mark, On 6/18/14 5:40 PM, Mark Thomas wrote: I have been thinking about connector refactoring for Tomcat 9. Currently BIO is planned to be dropped due to the number of features in the servlet spec that rely on non-blocking IO. I would like to propose dropping support for Comet in Tomcat 9 onwards. The reasons are: - WebSocket is already far more popular (based on question volume on the users list) - Comet support adds a fair amount of complexity to the connector code Thoughts? Keep in mind that 8.0.x isn't stable yet and any 9.0.x is likely to be several years away. +1 to remove Comet from 9.0.x. Tomcat 8 isn't stable? (!) -chris signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Drop comet support in Tomcat 9 onwards
On 02/12/2014 22:17, Christopher Schultz wrote: Mark, On 6/18/14 5:40 PM, Mark Thomas wrote: I have been thinking about connector refactoring for Tomcat 9. Currently BIO is planned to be dropped due to the number of features in the servlet spec that rely on non-blocking IO. I would like to propose dropping support for Comet in Tomcat 9 onwards. The reasons are: - WebSocket is already far more popular (based on question volume on the users list) - Comet support adds a fair amount of complexity to the connector code Thoughts? Keep in mind that 8.0.x isn't stable yet and any 9.0.x is likely to be several years away. +1 to remove Comet from 9.0.x. Tomcat 8 isn't stable? (!) Check the date on the original message. The first stable 8.0.x release was 8.0.9 on June 24 2014, 6 days after I sent that message. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1643008 - in /tomcat/trunk/java/org/apache/tomcat/websocket: Util.java pojo/PojoMethodMapping.java
2014-12-02 23:12 GMT+01:00 Mark Thomas ma...@apache.org: On 02/12/2014 21:16, r...@apache.org wrote: Author: remm Date: Tue Dec 2 21:16:51 2014 New Revision: 1643008 URL: http://svn.apache.org/r1643008 Log: Websockets annotations can be located on superclasses, and also improve duplicates detection. No they can't. See section 4.8 of the Java WebSocket specification that explicitly states that this is not allowed. Ah actually, it is a mix then of the two, it should implement what is marked as WSC-4.8.1 in the spec instead. Rémy
[Bug 55837] ServletContext.getRealPath() returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=55837 --- Comment #10 from Jo Desmet jo_des...@yahoo.com --- Just tested this in 8.0.3 log.info(Path3: +request.getRealPath(/)); // Works log.info(Path4: +request.getRealPath(\\)); // returns null!! log.info(Path2: +request.getRealPath(File.separator)); Second version returns null - however was working fine in Tomcat 7. Third version works on Unix, fails on Windows (for obvious reasons, but documenting it as a variation). Independent of whether it should be fixed or not - I am just adding the comment for future reference (someone else will stumble on it eventually). -- 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-validate (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-validate has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 9.x, a web server implementing the Java Servlet 4.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 25 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/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/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20141203.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.3.1-SNAPSHOT.j ar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20141203.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20141203.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20141203.jar:/srv/gump/packages/guava/guava-18.0.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp compile-prepare: download-validate: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar setproxy: downloadfile: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 6.2-SNAPSHOT on 2894 files [checkstyle] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java:52: 'org.apache.catalina.Context' should be separated from previous imports. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java:413: Line matches the illegal pattern '\s+$'. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java:435: Line matches the illegal pattern '\s+$'. BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:542: Got 3 errors and 0 warnings. Total time: 25 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 2014120305, vmgump.apache.org:vmgump:2014120305 Gump E-mail Identifier (unique within run) #7. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-tc8.0.x-validate (in module tomcat-8.0.x) 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-tc8.0.x-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 5 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc8.0.x-validate : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/gump_work/build_tomcat-8.0.x_tomcat-tc8.0.x-validate.html Work Name: build_tomcat-8.0.x_tomcat-tc8.0.x-validate (Type: Build) Work ended in a state of : Failed Elapsed: 25 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-8.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/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/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20141203.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.3.1-SNAPSHOT.j ar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20141203.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20141203.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-20141203.jar:/srv/gump/packages/guava/guava-18.0.jar - Buildfile: /srv/gump/public/workspace/tomcat-8.0.x/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-8.0.x/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-8.0.x/output/build/temp compile-prepare: download-validate: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-6.2-SNAPSHOT.jar setproxy: downloadfile: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-8.0.x/output/res/checkstyle [checkstyle] Running Checkstyle 6.2-SNAPSHOT on 2926 files [checkstyle] /srv/gump/public/workspace/tomcat-8.0.x/webapps/docs/changelog.xml:66: Line matches the illegal pattern '\s+$'. BUILD FAILED /srv/gump/public/workspace/tomcat-8.0.x/build.xml:542: Got 1 errors and 0 warnings. Total time: 24 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 2014120305, vmgump.apache.org:vmgump:2014120305 Gump E-mail Identifier (unique within run) #6. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57238] Updated SSL/TLS information for Tomcat 8/9
https://issues.apache.org/bugzilla/show_bug.cgi?id=57238 --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com --- (In reply to Christopher Schultz from comment #1) 0. Author tags have been discouraged, while the older contributors names have been left in for ... nostalgia? One should not add author tags. People are credited in commit message and changelog. 2. I wonder about the change in naming for the SSL sections to SSL/TLS. I think it's good, but might break URLs containing anchors in archives, other sites, etc. The page will still exist of course, only the anchor will no longer function. Perhaps you could add an explicit anchor alias using a name=Introduction to SSL!-- --/aa name=Introduction_to_SSL!-- --/a to be kind to the anchors. Hint: Anchor name can be set explicitly with anchor attribute on a section or subsection See r1643055 for an example. 3. Update document name in menu and on introduction page project.xml (SSL - SSL/TLS) index.xml -- 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
