Re: SPDY support
On 15/02/2012 03:53, Costin Manolache wrote: Uploaded another take. This time I'm just adding https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/LightHandler.java which is just a Handler - like AjpConnectionHandler, Http11ConnectionHandler. I believe this is as close to Endpoint intent as it can be - given this is a protocol at the same level with Ajp or http11. The only thing special is that the Endpoint must have both the regular Http11ConnectionHandler and a SpdyHandler - and chose one or the other based on TLS negotiation result. Sorry for not providing enough background: SPDY as specified and implemented by browsers only works over TLS, and only if the server negotiates it using the NPN TLS extension ( which only works for openssl - so APR ). Firefox doesn't support any 'non secure' mode, Chrome can be started with some parameters (--use-spdy=no-compress,no-ssl), but won't be able to connect to google or other spdy servers. Ah. That explains quite a few things. I was beginning to get that impression but the draft specs I was looking at didn't make that clear at all. I added it to the JIO endpoint for testing - and because I believe it is a great protocol for internal server-to-server connections, in which case no browser is involved and you can set it without ssl ( and without the header compression, which is another requirement ). Thanks. The fog is starting to lift now. On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas ma...@apache.org wrote: I hope the new interface does - it's just a small extension to Handler ( the main method is present in all other protocol implementations ) I haven't had a chance to look at it yet but I wanted to respond to the rest of your points. Does it need the socket or are input and output streams sufficient? It needs the APR socket to call JNI getNPN. I could make it work with the UpgradeAprProtocol eventually (making the socket available), but it feels more complex and intrusive, there are too many extra things. Fair enough. It may be that UpgradeXXXProtocol ends up extending the LightProtocol. Given the relative complexities / baggage if anything extends anything that seems the way to go right now (keeping in mind I haven't looked at your new code at all yet). Processor is tied to one request/response - Spdy protocol is a multiplexing protocol, so one spdy connection will have 100s of Requests. I am using Processor interface for each muxed spdy stream. Hmm. I wonder if we need a different name than Processor just to clarify the difference? But that is more a cosmetic issue. Plus - both are quite rich objects. I think it's worth using a smaller interface ( i.e. Endpoint.Handler with few extra extensions). I'd be prepared to trade a little bit of extra baggage (as I have with much of the connector refactoring) to increase commonality between components and reduce code duplication. What that means for SPDY I don't know yet. Again, I need to look at your latest proposal. This is more a general statement of the compromises I am happy making for easier maintenance. I don't think the LightHandler will affect the rest of the protocol code - it is pretty well separated, doesn't leak into coyote. Let me look at the latest proposal. The main point is that SPDY is selected after the TLS hanshake. ( with the benefit of saving one roundtrip - which is needed for websocket upgrade). As above, this dependency wasn't clear to me based on what I read. Things make a lot more sense now. Also: the current upgrade is quite heavy, it holds Requet/Response and a bunch of buffers. No it doesn't. Take another look at the code. The original implementation did but as I stated at the time my intention was to do some further refactoring to fix that. That refactoring has been complete (and is what resulted in the API changes I was referring to previously). Yes, much better now ! ( but still I don't think it's the best fit ). Thanks. Suggestions for improvements welcome. I would be happy to use the interfaces for websocket-over-spdy. Great. Having skimmed the latest SPDY draft spec at this point, it looks more like a protocol switch would be required rather than running WebSocket over SPDY. The protocols look to have a lot in common and I'm not sure I see the point of running WebSocket over SPDY. The point is that one TCP connection ( and more important - one TLS handshake ) is used for all websocket and GET/POST requests for a site. If you have a page that uses websocket - and also has many resources, uses ajax, etc - it'll end up as a single long-lived TCP connection for all of them. Got it. SPDY can't be used with NIO - JSSE doesn't have the 'next protocol negotiation' extension which is required by SPDY. Again, got it. That assumes that there is only a single TCP connection between HTTPD and Tomcat. I'm not sure how valid that would be given that HTTPD is
Re: SPDY support
On 02/15/2012 04:53 AM, Costin Manolache wrote: Uploaded another take. For non-SSL ( JIO, and apr without ssl ) - SPDY just kicks in on all connections, this is just a short-cut for testing. I could also define a SpdyProtocol and set it directly on the connector - but seems too much overhead for something that is testing/experimental. If we are going to consider this as AJP alternative (++1) then the SSL would definitely be handy (doesn't have to be TLS in that case, although some contemporary JVMs might support it) One of the major problems why users choose https over ajp for server-server communication is that (viable or not) So I'm not sure how SPDY is 'customizable' for allowing different transport layers. eg. can it use SSLv23 instead TLSv1 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52669] Annotation processing, in WEB-INF/classes, for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scen
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 violet...@apache.org changed: What|Removed |Added Summary|Annotation processing for |Annotation processing, in |Servlets/Listeners/Filters |WEB-INF/classes, for |is skipped when the web app |Servlets/Listeners/Filters |is not extracted, classes |is skipped when the web app |do not have packages and|is not extracted, classes |for some embedded scenarios |do not have packages and ||for some embedded scenarios -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52671] New: NIO Connector: Exception invoking method readBufSize / writeBufSize in the JMX Proxy Servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=52671 Bug #: 52671 Summary: NIO Connector: Exception invoking method readBufSize / writeBufSize in the JMX Proxy Servlet Product: Tomcat 7 Version: 7.0.25 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: sven@woltmann.com Classification: Unclassified JDK versions tested with: 1.7.0_02 (x64) and 1.7.0_03 (x64) I am using the new NIO connector, configured like this: Connector protocol=org.apache.coyote.ajp.AjpNioProtocol port=8009 redirectPort=8443 URIEncoding=UTF-8 maxThreads=50 minSpareThreads=10 connectionTimeout=60 acceptorThreadCount=2 / I query the JMX proxy for the thread pool status like this: http://www.mydomain.com/manager/jmxproxy/?qry=Catalina:type=ThreadPool,name=%22ajp-nio-8009%22 The JMX proxy servlet returns a valid response, and the server's general operation is not affected in any way. But at the same time, Tomcat logs the following two exceptions to catalina.out: Feb 15, 2012 12:26:49 PM org.apache.catalina.mbeans.MBeanDumper dumpBeans Schwerwiegend: Error getting attribute Catalina:type=ThreadPool,name=ajp-nio-8009 readBufSize javax.management.RuntimeOperationsException: Exception invoking method readBufSize at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:197) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:668) at org.apache.catalina.mbeans.MBeanDumper.dumpBeans(MBeanDumper.java:81) at org.apache.catalina.manager.JMXProxyServlet.listBeans(JMXProxyServlet.java:166) at org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.ajp.AjpNioProcessor.process(AjpNioProcessor.java:184) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1600) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.NullPointerException at org.apache.tomcat.util.net.SocketProperties.getRxBufSize(SocketProperties.java:251) at org.apache.tomcat.util.net.NioEndpoint.getReadBufSize(NioEndpoint.java:613) at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:190) ... 25 more Feb 15, 2012 12:26:49 PM org.apache.catalina.mbeans.MBeanDumper dumpBeans Schwerwiegend: Error getting attribute Catalina:type=ThreadPool,name=ajp-nio-8009 writeBufSize javax.management.RuntimeOperationsException: Exception invoking method writeBufSize at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(BaseModelMBean.java:197) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647) at
Re: SPDY support
On 15/02/2012 03:53, Costin Manolache wrote: Uploaded another take. This time I'm just adding https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/LightHandler.java which is just a Handler - like AjpConnectionHandler, Http11ConnectionHandler. I believe this is as close to Endpoint intent as it can be - given this is a protocol at the same level with Ajp or http11. I should have looked at this earlier. It is simpler than I was expecting. It looks good to me. The only thing special is that the Endpoint must have both the regular Http11ConnectionHandler and a SpdyHandler - and chose one or the other based on TLS negotiation result. I'd like to see the code for that but the approach seems reasonable. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244511 - /tomcat/trunk/build.properties.default
Author: markt
Date: Wed Feb 15 14:48:52 2012
New Revision: 1244511
URL: http://svn.apache.org/viewvc?rev=1244511view=rev
Log:
Update to Commons Daemon 1.0.9
Modified:
tomcat/trunk/build.properties.default
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1244511r1=1244510r2=1244511view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Wed Feb 15 14:48:52 2012
@@ -164,7 +164,7 @@ nsis.nsisdl.dll=${nsis.home}/Plugins/NSI
nsis.loc=${base-sf.loc}/nsis/nsis-2.46.zip
# - Commons Daemon, version 1.0-Alpha or later -
-commons-daemon.version=1.0.8
+commons-daemon.version=1.0.9
commons-daemon.home=${base.path}/commons-daemon-${commons-daemon.version}
commons-daemon.jar=${commons-daemon.home}/commons-daemon-${commons-daemon.version}.jar
commons-daemon.native.win.home=${commons-daemon.home}/windows
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244519 - in /tomcat/tc7.0.x/trunk: ./ build.properties.default webapps/docs/changelog.xml
Author: markt Date: Wed Feb 15 14:57:06 2012 New Revision: 1244519 URL: http://svn.apache.org/viewvc?rev=1244519view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 Update Commons Daemon to 1.0.9 Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/build.properties.default tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Feb 15 14:57:06 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129
svn commit: r1244520 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Feb 15 14:59:05 2012 New Revision: 1244520 URL: http://svn.apache.org/viewvc?rev=1244520view=rev 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=1244520r1=1244519r2=1244520view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Feb 15 14:59:05 2012 @@ -125,6 +125,12 @@ PATCHES PROPOSED TO BACKPORT: +1: markt -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 + Upgrade to Commons Daemon 1.0.9 + http://svn.apache.org/viewvc?rev=1244519view=rev + +1: markt + -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: r1244524 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: markt Date: Wed Feb 15 15:00:25 2012 New Revision: 1244524 URL: http://svn.apache.org/viewvc?rev=1244524view=rev Log: Proposal Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=1244524r1=1244523r2=1244524view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Feb 15 15:00:25 2012 @@ -36,3 +36,7 @@ PATCHES PROPOSED TO BACKPORT: +1: kfujino -1: +* Upgrade to Commons Daemon 1.0.9 + http://svn.apache.org/viewvc?rev=1244511view=rev + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52548] service.bat fails to set catalina.base and catalina.home due to apparent procrun bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=52548 Mark Thomas ma...@apache.org changed: What|Removed |Added Component|Integration |Native:Packaging Version|7.0.25 |6.0.35 Product|Tomcat 7|Tomcat 6 Target Milestone|--- |default --- Comment #2 from Mark Thomas ma...@apache.org 2012-02-15 15:01:58 UTC --- Fixed in trunk and 7.0.x and will be included in 7.0.26 onwards by upgrading to Daemon 1.0.9. The same upgrade has been proposed for 6.0.x and 5.5.x but note that 5.5.x is not affected by this bug since it currently uses Daemon 1.0.7. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: SPDY support
On Wed, Feb 15, 2012 at 6:33 AM, Mark Thomas ma...@apache.org wrote: On 15/02/2012 03:53, Costin Manolache wrote: Uploaded another take. This time I'm just adding https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/LightHandler.java which is just a Handler - like AjpConnectionHandler, Http11ConnectionHandler. I believe this is as close to Endpoint intent as it can be - given this is a protocol at the same level with Ajp or http11. I should have looked at this earlier. It is simpler than I was expecting. It looks good to me. The only thing special is that the Endpoint must have both the regular Http11ConnectionHandler and a SpdyHandler - and chose one or the other based on TLS negotiation result. I'd like to see the code for that but the approach seems reasonable. All the code is in my github clone. Diff against svn to see what changed. Costin Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
On Wed, Feb 15, 2012 at 12:56 AM, Mladen Turk mt...@apache.org wrote: On 02/15/2012 04:53 AM, Costin Manolache wrote: Uploaded another take. For non-SSL ( JIO, and apr without ssl ) - SPDY just kicks in on all connections, this is just a short-cut for testing. I could also define a SpdyProtocol and set it directly on the connector - but seems too much overhead for something that is testing/experimental. If we are going to consider this as AJP alternative (++1) then the SSL would definitely be handy (doesn't have to be TLS in that case, although some contemporary JVMs might support it) One of the major problems why users choose https over ajp for server-server communication is that (viable or not) I don't see any problem here - you can use 'secure' on the jio connector. Or we can modify the APR connector to allow proxy mode for the spdy connection. To make the proxy work - it'll need additional code to read and trust some X- headers from the real frontend ( client cert, ip, etc ). I haven't implemented this part yet for either 'real' spdy or proxy. So I'm not sure how SPDY is 'customizable' for allowing different transport layers. eg. can it use SSLv23 instead TLSv1 Real spdy requires TLS handshake - I don't remember the minimum version. For proxy you can use whatever you want. Costin Regards -- ^TM --**--**- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
On Wed, Feb 15, 2012 at 12:34 AM, Mark Thomas ma...@apache.org wrote: Processor is tied to one request/response - Spdy protocol is a multiplexing protocol, so one spdy connection will have 100s of Requests. I am using Processor interface for each muxed spdy stream. Hmm. I wonder if we need a different name than Processor just to clarify the difference? But that is more a cosmetic issue. It's probably too big change. Maybe some more javadocs ( I added a few where I had to figure things out ) :-) Plus - both are quite rich objects. I think it's worth using a smaller interface ( i.e. Endpoint.Handler with few extra extensions). I'd be prepared to trade a little bit of extra baggage (as I have with much of the connector refactoring) to increase commonality between components and reduce code duplication. What that means for SPDY I don't know yet. Again, I need to look at your latest proposal. This is more a general statement of the compromises I am happy making for easier maintenance. I agree in general. What I'm trying to do with spdy is keep the spdy package mostly dependence-free, with the tomcat specific code well isolated. After I submit, I'll give a try to changing SocketWrapper (non-generic, add read/write), in the git. If you don't like it - easy to drop the branch, but I think it'll simplify the old connectors enough to compensate for the extra complexity I'm adding :-) Also: the current upgrade is quite heavy, it holds Requet/Response and a bunch of buffers. No it doesn't. Take another look at the code. The original implementation did but as I stated at the time my intention was to do some further refactoring to fix that. That refactoring has been complete (and is what resulted in the API changes I was referring to previously). Yes, much better now ! ( but still I don't think it's the best fit ). Thanks. Suggestions for improvements welcome. Well, UpgradeProtocol has read/write methods, I would drop the streams ( keep them as separate util classes if someone wants them). I would also drop the methods reading/writing a single byte, use only byte[]. I think most improvements I can think of involve removing code :-) For non-SSL ( JIO, and apr without ssl ) - SPDY just kicks in on all connections, Ah. Light dawns. Do you see a requirement for non-SSL connections to be able to use HTTP or SPDY in the same way SSL ones can? For the proxy use case, an assumption of all SPDY seems valid. Yes, there is a special header that needs to be set ( if tomcat SPDY is working ), browsers will stop sending http and switch to spdy ( they'll also remember for next time ). Costin this is just a short-cut for testing. I could also define a SpdyProtocol and set it directly on the connector - but seems too much overhead for something that is testing/experimental. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244567 - in /tomcat/trunk: java/org/apache/el/lang/ELSupport.java test/org/apache/el/lang/TestELSupport.java
Author: markt
Date: Wed Feb 15 16:26:08 2012
New Revision: 1244567
URL: http://svn.apache.org/viewvc?rev=1244567view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52666
Correct coercion order in EL for A {==,!=,eq,ne} B
Modified:
tomcat/trunk/java/org/apache/el/lang/ELSupport.java
tomcat/trunk/test/org/apache/el/lang/TestELSupport.java
Modified: tomcat/trunk/java/org/apache/el/lang/ELSupport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?rev=1244567r1=1244566r2=1244567view=diff
==
--- tomcat/trunk/java/org/apache/el/lang/ELSupport.java (original)
+++ tomcat/trunk/java/org/apache/el/lang/ELSupport.java Wed Feb 15 16:26:08 2012
@@ -127,35 +127,31 @@ public class ELSupport {
return true;
} else if (obj0 == null || obj1 == null) {
return false;
-} else if (obj0 instanceof Boolean || obj1 instanceof Boolean) {
-return coerceToBoolean(obj0).equals(coerceToBoolean(obj1));
-} else if (obj0.getClass().isEnum()) {
-return obj0.equals(coerceToEnum(obj1, obj0.getClass()));
-} else if (obj1.getClass().isEnum()) {
-return obj1.equals(coerceToEnum(obj0, obj1.getClass()));
-} else if (obj0 instanceof String || obj1 instanceof String) {
-int lexCompare =
coerceToString(obj0).compareTo(coerceToString(obj1));
-return (lexCompare == 0) ? true : false;
-}
-if (isBigDecimalOp(obj0, obj1)) {
+} else if (isBigDecimalOp(obj0, obj1)) {
BigDecimal bd0 = (BigDecimal) coerceToNumber(obj0,
BigDecimal.class);
BigDecimal bd1 = (BigDecimal) coerceToNumber(obj1,
BigDecimal.class);
return bd0.equals(bd1);
-}
-if (isDoubleOp(obj0, obj1)) {
+} else if (isDoubleOp(obj0, obj1)) {
Double d0 = (Double) coerceToNumber(obj0, Double.class);
Double d1 = (Double) coerceToNumber(obj1, Double.class);
return d0.equals(d1);
-}
-if (isBigIntegerOp(obj0, obj1)) {
+} else if (isBigIntegerOp(obj0, obj1)) {
BigInteger bi0 = (BigInteger) coerceToNumber(obj0,
BigInteger.class);
BigInteger bi1 = (BigInteger) coerceToNumber(obj1,
BigInteger.class);
return bi0.equals(bi1);
-}
-if (isLongOp(obj0, obj1)) {
+} else if (isLongOp(obj0, obj1)) {
Long l0 = (Long) coerceToNumber(obj0, Long.class);
Long l1 = (Long) coerceToNumber(obj1, Long.class);
return l0.equals(l1);
+} else if (obj0 instanceof Boolean || obj1 instanceof Boolean) {
+return coerceToBoolean(obj0).equals(coerceToBoolean(obj1));
+} else if (obj0.getClass().isEnum()) {
+return obj0.equals(coerceToEnum(obj1, obj0.getClass()));
+} else if (obj1.getClass().isEnum()) {
+return obj1.equals(coerceToEnum(obj0, obj1.getClass()));
+} else if (obj0 instanceof String || obj1 instanceof String) {
+int lexCompare =
coerceToString(obj0).compareTo(coerceToString(obj1));
+return (lexCompare == 0) ? true : false;
} else {
return obj0.equals(obj1);
}
Modified: tomcat/trunk/test/org/apache/el/lang/TestELSupport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/el/lang/TestELSupport.java?rev=1244567r1=1244566r2=1244567view=diff
==
--- tomcat/trunk/test/org/apache/el/lang/TestELSupport.java (original)
+++ tomcat/trunk/test/org/apache/el/lang/TestELSupport.java Wed Feb 15 16:26:08
2012
@@ -23,11 +23,17 @@ import javax.el.ELException;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertTrue;
import org.junit.Test;
public class TestELSupport {
@Test
+public void testEquals() {
+assertTrue(ELSupport.equals(01, Long.valueOf(1)));
+}
+
+@Test
public void testBigDecimal() {
testIsSame(new BigDecimal(
0.123456789012345678901234567890123456789012345678901234567890123456789));
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244574 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/el/lang/ELSupport.java test/org/apache/el/lang/TestELSupport.java webapps/docs/changelog.xml
Author: markt
Date: Wed Feb 15 16:30:37 2012
New Revision: 1244574
URL: http://svn.apache.org/viewvc?rev=1244574view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52666
Correct coercion order in EL for A {==,!=,eq,ne} B
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/el/lang/ELSupport.java
tomcat/tc7.0.x/trunk/test/org/apache/el/lang/TestELSupport.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Feb 15 16:30:37 2012
@@ -1 +1 @@
-/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096
,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187
381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1
201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129
svn commit: r1244575 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt
Date: Wed Feb 15 16:31:36 2012
New Revision: 1244575
URL: http://svn.apache.org/viewvc?rev=1244575view=rev
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=1244575r1=1244574r2=1244575view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Feb 15 16:31:36 2012
@@ -131,6 +131,12 @@ PATCHES PROPOSED TO BACKPORT:
+1: markt
-1:
+* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52666
+ Correct coercion order in EL for A {==,!=,eq,ne} B
+ http://svn.apache.org/viewvc?rev=1244567view=rev
+ +1: markt
+ -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
DO NOT REPLY [Bug 52666] EL should coerce String to Integer in equals operation
https://issues.apache.org/bugzilla/show_bug.cgi?id=52666 Mark Thomas ma...@apache.org changed: What|Removed |Added Component|Jasper |Jasper Version|7.0.25 |6.0.35 Product|Tomcat 7|Tomcat 6 Target Milestone|--- |default --- Comment #1 from Mark Thomas ma...@apache.org 2012-02-15 17:13:27 UTC --- Fixed in trunk and 7.0.x and will be included in 7.0.26 onwards. the fix has been proposed for 6.0.x. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: SPDY support
On 15/02/2012 16:11, Costin Manolache wrote: After I submit, I'll give a try to changing SocketWrapper (non-generic, add read/write), in the git. If you don't like it - easy to drop the branch, but I think it'll simplify the old connectors enough to compensate for the extra complexity I'm adding :-) Sounds good. Well, UpgradeProtocol has read/write methods, I would drop the streams ( keep them as separate util classes if someone wants them). I would also drop the methods reading/writing a single byte, use only byte[]. I'd love to drop the streams and just use the message based API but the WebSocket protocol design is such that it needs to support streaming to stand any chance of being remotely scalable / efficient given the frankly crazy maximum message size. Maybe after things have bedded in for a while, we'll see which API folks are using and if there is zero demand for the stream based API we can drop that part and simplify the code accordingly. I think most improvements I can think of involve removing code :-) Those are always my favourite changes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244638 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java
Author: markt Date: Wed Feb 15 18:39:29 2012 New Revision: 1244638 URL: http://svn.apache.org/viewvc?rev=1244638view=rev Log: Fix refactoring snafu Modified: tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java Modified: tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java?rev=1244638r1=1244637r2=1244638view=diff == --- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java (original) +++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeProcessor.java Wed Feb 15 18:39:29 2012 @@ -21,7 +21,6 @@ import java.util.concurrent.Executor; import org.apache.coyote.Processor; import org.apache.coyote.Request; -import org.apache.coyote.http11.Constants; import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState; import org.apache.tomcat.util.net.SSLSupport; import org.apache.tomcat.util.net.SocketStatus; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244639 - in /tomcat/trunk/java/org/apache/coyote/http11/upgrade: UpgradeAprProcessor.java UpgradeBioProcessor.java UpgradeNioProcessor.java UpgradeOutbound.java
Author: markt
Date: Wed Feb 15 18:40:19 2012
New Revision: 1244639
URL: http://svn.apache.org/viewvc?rev=1244639view=rev
Log:
UCDetector warnings
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeAprProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeBioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeOutbound.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeAprProcessor.java?rev=1244639r1=1244638r2=1244639view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeAprProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeAprProcessor.java
Wed Feb 15 18:40:19 2012
@@ -29,7 +29,7 @@ import org.apache.tomcat.util.net.Socket
*/
public class UpgradeAprProcessor extends UpgradeProcessorLong {
-long socket;
+private final long socket;
public UpgradeAprProcessor(SocketWrapperLong wrapper,
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeBioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeBioProcessor.java?rev=1244639r1=1244638r2=1244639view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeBioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeBioProcessor.java
Wed Feb 15 18:40:19 2012
@@ -31,8 +31,8 @@ import org.apache.tomcat.util.net.Socket
*/
public class UpgradeBioProcessor extends UpgradeProcessorSocket {
-private InputStream inputStream;
-private OutputStream outputStream;
+private final InputStream inputStream;
+private final OutputStream outputStream;
public UpgradeBioProcessor(SocketWrapperSocket wrapper,
UpgradeInbound upgradeInbound) throws IOException {
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java?rev=1244639r1=1244638r2=1244639view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
Wed Feb 15 18:40:19 2012
@@ -33,8 +33,8 @@ import org.apache.tomcat.util.net.Socket
*/
public class UpgradeNioProcessor extends UpgradeProcessorNioChannel {
-private NioChannel nioChannel;
-private NioSelectorPool pool;
+private final NioChannel nioChannel;
+private final NioSelectorPool pool;
public UpgradeNioProcessor(SocketWrapperNioChannel wrapper,
UpgradeInbound upgradeInbound, NioSelectorPool pool) {
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeOutbound.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeOutbound.java?rev=1244639r1=1244638r2=1244639view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeOutbound.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeOutbound.java Wed
Feb 15 18:40:19 2012
@@ -32,7 +32,7 @@ public class UpgradeOutbound extends Out
processor.flush();
}
-private UpgradeProcessor? processor;
+private final UpgradeProcessor? processor;
public UpgradeOutbound(UpgradeProcessor? processor) {
this.processor = processor;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
On Wed, Feb 15, 2012 at 10:31 AM, Mark Thomas ma...@apache.org wrote: On 15/02/2012 16:11, Costin Manolache wrote: After I submit, I'll give a try to changing SocketWrapper (non-generic, add read/write), in the git. If you don't like it - easy to drop the branch, but I think it'll simplify the old connectors enough to compensate for the extra complexity I'm adding :-) Sounds good. Well, UpgradeProtocol has read/write methods, I would drop the streams ( keep them as separate util classes if someone wants them). I would also drop the methods reading/writing a single byte, use only byte[]. I'd love to drop the streams and just use the message based API but the WebSocket protocol design is such that it needs to support streaming to stand any chance of being remotely scalable / efficient given the frankly crazy maximum message size. I think it's not as bad, and crazy-size frame can be split - users need a callback when a new message started, than can call UpgradedProtocol.read([]) until the message is done. In spdy I'm using a SpdyFrame class ( spdy allow data frames to be fragmented any way you want by intermediary - so even if I receive a huge frame, I can split it in buffer-sized frames - I believe you can do the same for websocket, as long as you preserve the message boundaries), and return the real buffer to avoid the copy required for read(b[]). But of it involves a releaseBuffer(). Take a look - if/when we have websocket-over-spdy it would be good to be consistent. Costin Maybe after things have bedded in for a while, we'll see which API folks are using and if there is zero demand for the stream based API we can drop that part and simplify the code accordingly. I think most improvements I can think of involve removing code :-) Those are always my favourite changes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51741] Eclipse WTP Serve modules without publishing broken with tc7, needs patch in tomcat
https://issues.apache.org/bugzilla/show_bug.cgi?id=51741 --- Comment #12 from Mark Thomas ma...@apache.org 2012-02-15 19:59:18 UTC --- Note that the patch to ContextConfig contained invalid assumptions that triggered regressions (see bug 52669). Namely: - the patch assumed that web applications were always deployed in exploded form - the patch assumed that classes were always located in packages The patch also broke OSGi embedded usage. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52669] Annotation processing, in WEB-INF/classes, for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scen
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 Mike Youngstrom you...@gmail.com changed: What|Removed |Added CC||you...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Tomcat web site UI update
That is a comment that the layout needs to be cleaner (a comment I agree with). I agree too. I tried to create a cleaner layout and I posted a mockup for all to see and voice their opinions. https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg I'll leave it to Mark, Konstantin, Wesley and whomever else to let me know when it is reasonable to move forward. Cheers, Jeremy On Tue, Feb 14, 2012 at 11:40 AM, Mark Thomas ma...@apache.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/02/2012 16:21, Christopher Schultz wrote: Mark, On 2/13/12 5:28 PM, Mark Thomas wrote: On 13/02/2012 20:11, Christopher Schultz wrote: IIRC, Pid did a bunch of work toward that end and it was ultimately vetoed Reference please. That is not my recollection at all. Markmail remembers: http://markmail.org/message/og235cbvrdluiejg That isn't a veto. That is a comment that the layout needs to be cleaner (a comment I agree with). From a style point of view it is a big improvement. Mark My recollection was that pid started down this road but hasn't found the time to finish it, or at least get it to a state where enough was complete that it could be committed. Konstantin liked it for the ROOT webapp, but not the Tomcat main site. Same with Wesley Acheson. -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOpx3AAoJEBDAHFovYFnnxEIP/Rvhm+UYlVq5enUzWlPbLmWC ZPXcduolPXTVwU2jpIZpSw020677h92kq3dWFL7JSlKNhuHK2C/fS0iI9YYY0Xp/ L9qYf7fvzSvzka7wUFJxFXLwPX6uoDAFwFtr+KSBmus3S206elkCCtILB/z06itA VE31NVqOmXqLq7ZrqsE+4oxzqdkiJV1Cl1uKfR+O0LRJJ39Yl5+LyjThRDWdandC JoWDnJhz/rAWC473X4NWh9q0LXK04uiufvHN3qtq1tbjl2YQ2tkEdcgJilXXCOF/ NgcnvBlWw5R6o9w2Hm7X5xu6YAi8FS1sdWZ5QAihMud23pxT4KCUlK7DSzz2v3Yt vWXEWpbaOD7kFa2c1Wj8dxED4q9ZB8UZZfBkCpG/AGXA1W1DrygPOePkRCNMzBSe L7JWBU5CBJ6avlSnEFMXZIgXg/iVf0bGJUSZr+nL9auoDmJwyN46/HyDeK9ucWyn O6TTzCFgCrcI01k7sVt3vrmtX2/JcvF2O0XMGRYTD/6trFWg96eA7NeOab7Rq90S S6HcEFWGgM52/SibK49yc1J1oQvwNFHzZ2FNINMLBHRI4FjnbLbwxqF8IcZtKs+5 YlbpiiXz+9LIUS8negOTTStXJFqmGaauYMZmIDf7JxFfxozCCQsayifzn+62STrX bx3sI4uobJxVqoNNe++B =F97+ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SPDY support
On 15/02/2012 19:58, Costin Manolache wrote: In spdy I'm using a SpdyFrame class ( spdy allow data frames to be fragmented any way you want by intermediary - so even if I receive a huge frame, I can split it in buffer-sized frames - I believe you can do the same for websocket, as long as you preserve the message boundaries), and return the real buffer to avoid the copy required for read(b[]). But of it involves a releaseBuffer(). Take a look - if/when we have websocket-over-spdy it would be good to be consistent. Unfortunately that isn't guaranteed to be possible. To quote from the spec: An intermediary MUST NOT change the fragmentation of any message in the context of a connection where extensions have been negotiated and the intermediary is not aware of the semantics of the negotiated extensions. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244718 - in /tomcat/trunk/java/org/apache/catalina/startup: ContextConfig.java LocalStrings.properties
Author: markt
Date: Wed Feb 15 20:57:36 2012
New Revision: 1244718
URL: http://svn.apache.org/viewvc?rev=1244718view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52669
Correct regression introduced by the invalid assumptions made in the
hack for Eclipse to address
https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
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=1244718r1=1244717r2=1244718view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Wed Feb 15
20:57:36 2012
@@ -1156,6 +1156,8 @@ public class ContextConfig implements Li
parseWebXml(contextWebXml, webXml, false);
if (webXml.getMajorVersion() = 3) {
+ServletContext sContext = context.getServletContext();
+
// Ordering is important here
// Step 1. Identify all the JARs packaged with the application
@@ -1178,6 +1180,9 @@ public class ContextConfig implements Li
// Step 4. Process /WEB-INF/classes for annotations
// This will add any matching classes to the typeInitializerMap
if (ok) {
+// Hack required by Eclipse's serve modules without
+// publishing feature since this backs WEB-INF/classes by
+// multiple locations rather than one.
NamingEnumerationBinding listBindings = null;
try {
try {
@@ -1190,9 +1195,20 @@ public class ContextConfig implements Li
listBindings.hasMoreElements()) {
Binding binding = listBindings.nextElement();
if (binding.getObject() instanceof FileDirContext)
{
-File webInfCLassDir = new File(
+File webInfClassDir = new File(
((FileDirContext)
binding.getObject()).getDocBase());
-processAnnotationsFile(webInfCLassDir, webXml);
+processAnnotationsFile(webInfClassDir, webXml);
+} else {
+String resource =
+/WEB-INF/classes/ +
binding.getName();
+try {
+URL url = sContext.getResource(resource);
+processAnnotationsUrl(url, webXml);
+} catch (MalformedURLException e) {
+log.error(sm.getString(
+contextConfig.webinfClassesUrl,
+resource), e);
+}
}
}
} catch (NamingException e) {
@@ -1236,9 +1252,9 @@ public class ContextConfig implements Li
// from having to re-generate it.
// TODO Use a ServletContainerInitializer for Jasper
String mergedWebXml = webXml.toXml();
-context.getServletContext().setAttribute(
+sContext.setAttribute(
org.apache.tomcat.util.scan.Constants.MERGED_WEB_XML,
-mergedWebXml);
+ mergedWebXml);
if (context.getLogEffectiveWebXml()) {
log.info(web.xml:\n + mergedWebXml);
}
Modified: tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties?rev=1244718r1=1244717r2=1244718view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/startup/LocalStrings.properties Wed
Feb 15 20:57:36 2012
@@ -60,7 +60,7 @@ contextConfig.stop=ContextConfig: Proces
contextConfig.unavailable=Marking this application unavailable due to previous
error(s)
contextConfig.unknownUrlProtocol=The URL protocol [{0}] was not recognised
during annotation processing. URL [{1}] was ignored.
contextConfig.urlPatternValue=Both the UrlPattern and value attribute were set
for the WebServlet annotation on class [{0}]
-contextConfig.webinfClassesUrl=Unable to determine URL for WEB-INF/classes
svn commit: r1244719 - /tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java
Author: markt
Date: Wed Feb 15 20:58:16 2012
New Revision: 1244719
URL: http://svn.apache.org/viewvc?rev=1244719view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52671
Log NPEs for attributes that are not set at debug.
Modified:
tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java
Modified: tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java?rev=1244719r1=1244718r2=1244719view=diff
==
--- tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java (original)
+++ tomcat/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java Wed Feb 15
20:58:16 2012
@@ -85,6 +85,9 @@ public class MBeanDumper {
if (cause instanceof UnsupportedOperationException) {
log.debug(Error getting attribute + oname +
+ attName, rme);
+} else if (cause instanceof NullPointerException) {
+log.debug(Error getting attribute + oname +
+ + attName, rme);
} else {
log.error(Error getting attribute + oname +
+ attName, rme);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1244737 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java java/org/apache/catalina/startup/LocalStrings.properties webapps/docs/changelog.xml
Author: markt Date: Wed Feb 15 21:22:19 2012 New Revision: 1244737 URL: http://svn.apache.org/viewvc?rev=1244737view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 Correct regression introduced by the invalid assumptions made in the hack for Eclipse to address https://issues.apache.org/bugzilla/show_bug.cgi?id=51741 Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/LocalStrings.properties tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Feb 15 21:22:19 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129
AccessLogValve enhancement
We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add. There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class); This still makes a lot of sense, and should probably be kept separate. What I would propose is that a new attribute be added, called maybe systemLoggerName. If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.) I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates. I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate. Mark Valve className=org.apache.catalina.valves.AccessLogValve directory=log prefix=localhost_access_log. systemLoggerName=mylogger pattern=common resolveHosts=false/
Re: AccessLogValve enhancement
On 15/02/2012 21:23, Mark Claassen wrote: We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add. I added org.apache.juli.VerbatimFormatter some time ago with this in mind but never got around to implementing it. There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class); This still makes a lot of sense, and should probably be kept separate. +1 What I would propose is that a new attribute be added, called maybe systemLoggerName. If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.) aside Woot! A bike shed to paint. :) /aside outputLoggerName? I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates. I assume that the directory and prefix attributes below are unnecessary. I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate. There is a very detailed 143 page process document for approving changes like this. Fortunately it may be summed up as If you can convince a committer to make the change and no other committer vetos the change it will be in the next release.. As long as backwards compatibility is retained, I can't imagine why someone might complain (unless the patch is a mess). I also be +1 to considering making this the sole way AccessLogValve logging may be output. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52669] Annotation processing, in WEB-INF/classes, for Servlets/Listeners/Filters is skipped when the web app is not extracted, classes do not have packages and for some embedded scen
https://issues.apache.org/bugzilla/show_bug.cgi?id=52669 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Mark Thomas ma...@apache.org 2012-02-15 21:37:50 UTC --- This has been fixed in trunk and 7.0.x and will be included in 7.0.26 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1244746 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/mbeans/MBeanDumper.java webapps/docs/changelog.xml
Author: markt Date: Wed Feb 15 21:41:49 2012 New Revision: 1244746 URL: http://svn.apache.org/viewvc?rev=1244746view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52671 Log NPEs for attributes that are not set at debug. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/mbeans/MBeanDumper.java tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Feb 15 21:41:49 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129
DO NOT REPLY [Bug 52671] NIO Connector: Exception invoking method readBufSize / writeBufSize in the JMX Proxy Servlet
https://issues.apache.org/bugzilla/show_bug.cgi?id=52671 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2012-02-15 21:42:09 UTC --- Fixed in trunk and 7.0.x and will be included in 7.0.26 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1244747 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: markt Date: Wed Feb 15 21:48:58 2012 New Revision: 1244747 URL: http://svn.apache.org/viewvc?rev=1244747view=rev Log: Proposal Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=1244747r1=1244746r2=1244747view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Feb 15 21:48:58 2012 @@ -40,3 +40,9 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=1244511view=rev +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52640 + Correct endorsed dir location when using installer + http://people.apache.org/~markt/patches/2012-02-15-bug52640-tc5.patch + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52640] Installer sets endorsed dirs with /common/ missing from path
https://issues.apache.org/bugzilla/show_bug.cgi?id=52640 Mark Thomas ma...@apache.org changed: What|Removed |Added OS/Version||All --- Comment #1 from Mark Thomas ma...@apache.org 2012-02-15 21:49:01 UTC --- Patch proposed for 5.5.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: AccessLogValve enhancement
Awesome. Thanks for the immediate response! I see that the ExtendedAccessLogValve would need to be tweaked as well, and that one would loose the repeating header bit when using the system logger (or outputLogger) I guess th header could still be written on init (and maybe when the pattern changed?) writer.println(#Fields: + pattern); writer.println(#Version: 2.0); writer.println(#Software: + ServerInfo.getServerInfo()); I also be +1 to considering making this the sole way AccessLogValve logging may be output. +1 I assume that the directory and prefix attributes below are unnecessary. Yep. And a few others Based on your comments, I will go ahead and modify those to classes and then see where it goes from there. It will be completely backwards compatible. On Wed, Feb 15, 2012 at 4:33 PM, Mark Thomas ma...@apache.org wrote: On 15/02/2012 21:23, Mark Claassen wrote: We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add. I added org.apache.juli.VerbatimFormatter some time ago with this in mind but never got around to implementing it. There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class); This still makes a lot of sense, and should probably be kept separate. +1 What I would propose is that a new attribute be added, called maybe systemLoggerName. If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.) aside Woot! A bike shed to paint. :) /aside outputLoggerName? I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates. I assume that the directory and prefix attributes below are unnecessary. I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate. There is a very detailed 143 page process document for approving changes like this. Fortunately it may be summed up as If you can convince a committer to make the change and no other committer vetos the change it will be in the next release.. As long as backwards compatibility is retained, I can't imagine why someone might complain (unless the patch is a mess). I also be +1 to considering making this the sole way AccessLogValve logging may be output. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AccessLogValve enhancement
2012/2/16 Mark Claassen markclaass...@gmail.com: We would like to use the flexibility of the standard logging mechanism for the AccessLogValue. I could find no way to do this. Looking at the AccessLogValve code in Tomcat 7, it seems it would really would not be hard to add. There already is standard logger in the AccessLogValve class, which is where error in the logger itself get routed. private static final Log log = LogFactory.getLog(AccessLogValve.class); This still makes a lot of sense, and should probably be kept separate. What I would propose is that a new attribute be added, called maybe systemLoggerName. If this is set, then the logger by that name would be used instead of the current hard-coded file logger. (Errors would still go to the statically defined Logger.) I already tried this with the XML listed below and a slightly modified AccessLogValve and it seems to work perfectly. If this is something that would be considered a positive change, I would be happy to submit a patch and propose some documentation updates. I am not exactly sure how this all works, especially since this is more of an enhancement rather than a bug fix. I sure there are guidelines for when in a release cycle these types of changes are appropriate. Mark Valve className=org.apache.catalina.valves.AccessLogValve directory=log prefix=localhost_access_log. systemLoggerName=mylogger pattern=common resolveHosts=false/ I would say that the performance requirements for the two are different. Access log should be fast and simple. The error log does not have to be as fast, as errors should be more rare. The default JULI FileHandler is not suitable here. You have to configure buffers. You have to perform flushing. AccessLogValve wires to Tomcat's background processing, but IIRC you cann do flush via commons-logging wrapper. The only viable alternative here is AsyncFileHandler. You should also make sure that the events wouldn't be printed to Console. The ideas to extract some common code to elsewhere (e.g. time formatting cache) were spoken several times. They are feasible. Regarding this systemLoggerName (or logCategory as I would name it) feature, I think it does not belong to the current AccessLogValve but you might plug it there after some refactoring. Anyway I would like to see the whole picture, which includes the logging configuration that you would use with AccessLogValve. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
Hi, sorry for the delay, we got stalled a little bit, I'll post the patch today (US central time) after I manage to merge it (oh the cursed newlines). Thanks, Petr On Mon, Feb 13, 2012 at 14:18, Christopher Schultz ch...@christopherschultz.net wrote: Jeremy, On 2/10/12 12:08 PM, Jeremy Brown wrote: I suspect it will need more than that. The XLST will almost certainly need some tweaks too. How timely, I'm doing xml transformations in my SOA class right now. If you have any questions about XSLT, I'd be happy to answer them. It's definitely something that you have to have a Zenlike relationship with in order to do properly. Just like Lisp, it's possible to write really awful procedurally-oriented code with it, but then it just sucks horribly. We've been using XSLT for a long time with Apache Cocoon (such a great product) to transform XML into XHTML. I'd be happy to help. -chris
DO NOT REPLY [Bug 52677] New: embedded SetCharacterEncodingFilter in org.apache.catalina.filters is not usable as it does not implement javax.servlet.Filter
https://issues.apache.org/bugzilla/show_bug.cgi?id=52677 Bug #: 52677 Summary: embedded SetCharacterEncodingFilter in org.apache.catalina.filters is not usable as it does not implement javax.servlet.Filter Product: Tomcat 5 Version: 5.5.35 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: djhighm...@gmail.com Classification: Unclassified Version 5.5.35 added SetCharacterEncodingFilter to the org.apache.catalina.filters package so it is available for all web applications. It is documented at http://tomcat.apache.org/tomcat-5.5-doc/config/filter.html#Set_Character_Encoding_Filter Use of filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter-class however will fail with CastClassException in ApplicationFilterConfig.getFilter:209 as it does not implement javax.servlet.Filter This problem is not present in the 6.0 branch as SetCharacterEncodingFilter implements Filter there This problem is not present in the 7.0 branch as SetCharacterEncodingFilter extends FilterBase there Workaround: continue to use your own SetCharacterEncodingFilter that is based on the example in ./servletapi/jsr154/examples/WEB-INF/classes/filters/SetCharacterEncodingFilter.java instead of using the embedded one. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52677] embedded SetCharacterEncodingFilter in org.apache.catalina.filters is not usable as it does not implement javax.servlet.Filter
https://issues.apache.org/bugzilla/show_bug.cgi?id=52677 Gary Timuss djhighm...@gmail.com changed: What|Removed |Added Priority|P2 |P3 CC||djhighm...@gmail.com, ||knst.koli...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: SPDY support
On Wed, Feb 15, 2012 at 12:10 PM, Mark Thomas ma...@apache.org wrote: On 15/02/2012 19:58, Costin Manolache wrote: In spdy I'm using a SpdyFrame class ( spdy allow data frames to be fragmented any way you want by intermediary - so even if I receive a huge frame, I can split it in buffer-sized frames - I believe you can do the same for websocket, as long as you preserve the message boundaries), and return the real buffer to avoid the copy required for read(b[]). But of it involves a releaseBuffer(). Take a look - if/when we have websocket-over-spdy it would be good to be consistent. Unfortunately that isn't guaranteed to be possible. To quote from the spec: An intermediary MUST NOT change the fragmentation of any message in the context of a connection where extensions have been negotiated and the intermediary is not aware of the semantics of the negotiated extensions. That doesn't mean the application must receive the entire message as one byte[] or as a Stream. You can have a very large fragment but still read it in smaller buffers and notify the user of message start and for each fragment ( I guess like xml parsing ). Costin Mark - 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-eoln (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-eoln 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-eoln : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.jar. -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz. -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz. -DEBUG- Dependency on junit exists, no need to add for property junit.jar. -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp.home. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/gump_work/build_tomcat-trunk_tomcat-trunk-validate-eoln.html Work Name: build_tomcat-trunk_tomcat-trunk-validate-eoln (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-16022012.jar -Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-16022012-native-src.tar.gz -Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-16022012-native-src.tar.gz -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps -Djdt.jar=/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar -Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-16022012.jar -Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-src.jar -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat -dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-16022012.jar validate-eoln [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/classes:/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-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/servlet-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/el-api.j ar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-trunk/output/build/lib/tomcat-util.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/junit/dist/junit-16022012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-16022012.jar:/srv/gump/packages/eclipse/plugins/org.eclipse.jdt.core_3.4.2/jdtcore.jar:/srv/gum p/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-16022012.jar:/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-16022012.jar
[Tomcat Wiki] Trivial Update of GettingStarted by Keith Woodward
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The GettingStarted page has been changed by Keith Woodward: http://wiki.apache.org/tomcat/GettingStarted?action=diffrev1=14rev2=15 Comment: Important info for new starters about serving pages to the root domain. == Useful links == * HowTo - Some how-tos assembled here + * [[http://benhutchison.wordpress.com/2008/07/30/how-to-configure-tomcat-root-context/#comment-336]] How to make tomcat serve content from www.exampledomain.com instead of www.exampledomain.com/examplewebapp. Basically, just make a directory inside tomcat's webapps directory called ROOT and your content will be served to the root domain www.exampledomain.com. * [[http://bitnami.org/stack/tomcatstack|BitNami Tomcat Stack]]: Provides an all-in-one installer, free virtual machines and cloud images for Tomcat. * [[http://www.turnkeylinux.org/appliances/tomcat|TurnKey Tomcat Appliance]]: Open source installable Live CD based on Ubuntu. Features minimal footprint, automatic security updates, SSL support and an elegant Web administration interface. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket progress report
Hello, attached is our patch. It applies cleanly on top of current trunk rev. 1244719. It has rudimentary support for fragmentation (callback after last frame), supports close messages and ping/pong. Sorry for not sending a patchset but I thought it wouldn't really make sense, since there were quite a lot of back and forth changes. Let me know if I should send a patchset instead. (Jonathan's summary) Echoing fragments. Close messages. Pings/pongs. Just barely works. :) Fragmentation support is very limited: a mere callback when last frame received. Sends normal closing reply messages and some protocol error closes. Answers pings with pongs. Moving towards a better application API. The servlet container is doing something I don't understand with rapid connection attempts…not sure what's up. I renamed StreamInbound to WebSocketConnection since it's bidirectional. Also I gave the upgrade processors close() methods. Fixed a number of bugs, including a switch statement with accidentally cascading cases, and a problem with in Conversions.byteArrayToLong(). Thanks, Petr On Wed, Feb 15, 2012 at 17:17, Petr Praus p...@praus.net wrote: Hi, sorry for the delay, we got stalled a little bit, I'll post the patch today (US central time) after I manage to merge it (oh the cursed newlines). Thanks, Petr On Mon, Feb 13, 2012 at 14:18, Christopher Schultz ch...@christopherschultz.net wrote: Jeremy, On 2/10/12 12:08 PM, Jeremy Brown wrote: I suspect it will need more than that. The XLST will almost certainly need some tweaks too. How timely, I'm doing xml transformations in my SOA class right now. If you have any questions about XSLT, I'd be happy to answer them. It's definitely something that you have to have a Zenlike relationship with in order to do properly. Just like Lisp, it's possible to write really awful procedurally-oriented code with it, but then it just sucks horribly. We've been using XSLT for a long time with Apache Cocoon (such a great product) to transform XML into XHTML. I'd be happy to help. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
