DO NOT REPLY [Bug 50738] Manager.initInternal not invoked on context reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=50738 --- Comment #2 from Martin Grotzke 2011-02-09 02:59:46 EST --- For tomcat6 init was called on context reload (actually it's done in StandardContext.start: if (!initialized) init();). If it's intended that this behaviour is changed, then how do I know that I need to invoke initInternal by myself when startInternal is invoked (without doing this on a regular start)? I couldn't get this information from the state diagram in org.apache.catalina.Lifecycle. -- 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 39740] semi-colon ; isn't allowed as a query argument separator
https://issues.apache.org/bugzilla/show_bug.cgi?id=39740 --- Comment #11 from Konstantin Kolinko 2011-02-09 03:07:24 EST --- (In reply to comment #10) > until the W3C finally declares ';' as the > correct syntax, and not some obtuse footnote that contradicts their spec. I think it never happens. I do not see any traces of that footnote in HTML5 spec drafts. -- 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 50738] Manager.initInternal not invoked on context reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=50738 --- Comment #3 from Konstantin Kolinko 2011-02-09 03:10:55 EST --- > how do I know that I need to invoke initInternal by myself Why do you need to invoke it? -- 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: r1068787 - in /tomcat/site/trunk: docs/security-5.html docs/security-6.html docs/security-7.html xdocs/security-5.xml xdocs/security-6.xml xdocs/security-7.xml
Author: jfclere Date: Wed Feb 9 08:25:51 2011 New Revision: 1068787 URL: http://svn.apache.org/viewvc?rev=1068787&view=rev Log: See http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html Modified: tomcat/site/trunk/docs/security-5.html tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/docs/security-7.html tomcat/site/trunk/xdocs/security-5.xml tomcat/site/trunk/xdocs/security-6.xml tomcat/site/trunk/xdocs/security-7.xml Modified: tomcat/site/trunk/docs/security-5.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=1068787&r1=1068786&r2=1068787&view=diff == --- tomcat/site/trunk/docs/security-5.html (original) +++ tomcat/site/trunk/docs/security-5.html Wed Feb 9 08:25:51 2011 @@ -3,18 +3,18 @@ Apache Tomcat - Apache Tomcat 5 vulnerabilities - - - + + + - - + + http://tomcat.apache.org/";> - + @@ -25,28 +25,28 @@ http://www.apache.org/";> -http://www.apache.org/images/asf-logo.gif"; align="right" alt="Apache Logo" border="0"/> +http://www.apache.org/images/asf-logo.gif"; /> -http://www.google.com/search"; method="get"> - - - +http://www.google.com/search";> + + + - + - + - + Apache Tomcat @@ -178,11 +178,11 @@ - - + + - + @@ -264,14 +264,14 @@ - + - + - + @@ -312,14 +312,14 @@ - + - + - + @@ -328,8 +328,8 @@ - - + + released 1 Feb 2011 @@ -365,14 +365,14 @@ - + - + - + @@ -381,8 +381,8 @@ - - + + released 9 Jul 2010 @@ -475,14 +475,14 @@ - + - + - + @@ -491,8 +491,8 @@ - - + + released 20 Apr 2010 @@ -592,14 +592,14 @@ - + - + - + @@ -608,8 +608,8 @@ - - + + released 4 Sep 2009 @@ -737,14 +737,14 @@ - + - + - + @@ -753,8 +753,8 @@ - - + + released 8 Sep 2008 @@ -834,14 +834,14 @@ - + - + - + @@ -850,8 +850,8 @@ - - + + released 5 Feb 2008 @@ -917,14 +917,14 @@ - + - + - + @@ -933,8 +933,8 @@ - - + + released 8 Sep 2007 @@ -1014,14 +1014,14 @@ - + - + - + @@ -1030,8 +1030,8 @@ - - + + Not released @@ -1059,14 +1059,14 @@ - + - + - + @@ -1075,8 +1075,8 @@ - - + + released 9 Mar 2007 @@ -1109,14 +1109,14 @@ - + - + - + @@ -1125,8 +1125,8 @@ - - + + not released @@ -1178,14 +1178,14 @@ - + - + - + @@ -1194,8 +1194,8 @@ - - + + not released @@ -1226,14 +1226,14 @@ - + - + - + @@ -1242,8 +1242,8 @@ - - + + not released @@ -1286,14 +1286,14 @@ - + - + - + @@ -1302,8 +1302,8 @@ - - + + not released @@ -1329,14 +1329,14 @@ - + - + - + @@ -1345,8 +1345,8 @@ - - + + released 27 Apr 2006 @@ -1372,14 +1372,14 @@ - + - + - + @@ -1388,8 +1388,8 @@ - - + + released 15 Mar 2006 @@ -1415,14 +1415,14 @@ - + - + - + @@ -1473,14 +1473,14 @@ - + - + - + @@ -1511,14 +1511,14 @@ - + - + - + @@ -1553,14 +1553,14 @@ - + - + - + @@ -1577,8 +1577,8 @@ Important: Remote Denial Of Service - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-";> - CVE-2011- + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4476";> + CVE-2010-4476 A JVM bug could cause Double conversion to hang JVM when accessing to a @@ -1688,7 +1688,7 @@ - + @@ -1697,17 +1697,17 @@ - + - + Copyright © 1999-2011, The Apache Software Foundation - + Apache Tomcat, Tomcat, Apache, the Apache feather, and the Apache Tomcat project logo are trademarks of the Apache Software Foundation. Modified: tomcat/site/trunk/docs/security-6.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=1068787&r1=1068786&r2=1068787&view=diff == --- tomcat/site/trunk/docs/security-6.html (original) +++ tomcat/site/trunk/docs/security-6.html Wed Feb 9 08:25:51 2011 @@ -3,18 +3,18 @@ Apache Tomcat - Apache Tomcat 6 vulnerabilities - - - + + + - - + + http://tomcat.apache.org/";> - + @@ -25,28 +25,28 @@ http://www.apache.org/";> -http://www.apache.org/images/asf-logo.gif"; align="right" alt="Apache Logo" border="0"/> +http://www.apache.org/images/asf-logo.gif"; /> -http://www.google.com/search"; method="get"> - - - +http://www.google.com/search";> + + + - + - + - + Apache Tomcat @@ -178,11 +178,11 @@ - - + + - + @@ -246,14 +246,14 @@
DO NOT REPLY [Bug 50738] Manager.initInternal not invoked on context reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=50738 --- Comment #4 from Martin Grotzke 2011-02-09 03:40:13 EST --- As I'm doing my initialization in initInternal: https://github.com/magro/memcached-session-manager/blob/tomcat7/core/src/main/java/de/javakaffee/web/msm/MemcachedBackupSessionManager.java#L267 That was working fine for tomcat6. Should initialization be moved to startInternal? -- 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
Duplicate events in Lifecycle?
1) Browsing the code in o.a.c.startup.Embedded#stopInternal() I see the following two lines: fireLifecycleEvent(STOP_EVENT, null); setState(LifecycleState.STOPPING); Unless I miss something it means that STOP_EVENT is fired twice, once by the fireLifecycleEvent() call and second time by setState(). 2) Lifecycle#setState() does not check that new state != old state. It always fires a lifecycle event on every call. I see that some 3rd party components that extend ours (like the one mentioned in BZ 50738) call this.setState(STARTING), then call super.startInternal() that may fire the event second time. Shouldn't we avoid firing duplicate events? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50738] Manager.initInternal not invoked on context reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=50738 --- Comment #5 from Konstantin Kolinko 2011-02-09 04:21:13 EST --- (In reply to comment #4) > That was working fine for tomcat6. Should initialization be moved to > startInternal? Another solution could be to move destruction into destroyInternal. In any case, there should be symmetry inside init/destroy and start/stop pairs. -- 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: r1068808 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Author: kkolinko
Date: Wed Feb 9 09:35:16 2011
New Revision: 1068808
URL: http://svn.apache.org/viewvc?rev=1068808&view=rev
Log:
Followup to r1068549 - add annotations.
I thought about moving ErrorHandler instance creation outside the retry loop,
but actually that is not needed: looping happens only when asyncReply==false
and ErrorHandler is created only when asyncReply==true. Thus it is created only
once.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068808&r1=1068807&r2=1068808&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 09:35:16 2011
@@ -139,10 +139,11 @@ public class RpcChannel implements Chann
final Member fsender = sender;
if (excallback!=null && asyncReply) {
handler = new ErrorHandler() {
+@Override
public void handleError(ChannelException x, UniqueId
id) {
excallback.replyFailed(request, response, fsender,
x);
}
-
+@Override
public void handleCompletion(UniqueId id) {
excallback.replySucceeded(request, response,
fsender);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50738] Manager.initInternal not invoked on context reload
https://issues.apache.org/bugzilla/show_bug.cgi?id=50738 --- Comment #6 from Martin Grotzke 2011-02-09 04:40:28 EST --- I just overwrote destroyInternal and debugged/logged, but it seems to be not called for me, neither on context reload nor during stop (CTRL-C). Anyway, so I'll move initialization to startInternal. One suggestion though: please change the javadoc of LifecycleMBeanBase.initInternal() which is inherited/seen by subclasses so that it makes clear that initInternal is only invoked for initial start, but not during a reload. The current documentation (of LifecycleMBeanBase.initInternal) is not clear about this: /** * Sub-classes wishing to perform additional initialization should override * this method, ensuring that super.initInternal() is the first call in the * overriding method. */ -- 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 50734] 400 Bad Request when there are no web applications deployed on Tomcat 6.0.32
https://issues.apache.org/bugzilla/show_bug.cgi?id=50734 --- Comment #2 from violet...@apache.org 2011-02-09 04:42:50 EST --- Created an attachment (id=26626) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26626) 400 Bad Request issue - patch proposal Hi, Patch is made based on Tomcat 6.0.32 sources. Regards Violeta -- 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 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #12 from Olivier Costet 2011-02-09 04:59:37 EST --- Hi Filip, I would have thought the second callback could be implemented in the same class is the (Extended)RpcCallback, but at any rate it's your call. I got what I wanted out of this, so it's fine by me. A few remarks on the code: 1. Unless I'm very much mistaken, the retry functionality won't work in async mode. This should be documented in ExtendedRpcCallback#replyFailed. 2. As far as I can see, GroupChannel#send does handle the case where the ErrorHandler is null, so you probably don't need an if/else to call the appropriate Channel#send in RpcChannel#messageReceived. Actually, this would depend on the contract of Channel#send, which I'm not aware of, so I don't know for sure. 3. The call to ExtendedRpcCallback#replySucceeded in the synchronous case should be move outside the try/catch block. Perhaps put it in a try/catch of its own. The way it is now, it would cause spurious behaviour if it were to throw a RuntimeException. I think that's about it. Cheers, Olivier. -- 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 50743] New: Cache results to speed up Checkstyle #build
https://issues.apache.org/bugzilla/show_bug.cgi?id=50743
Summary: Cache results to speed up Checkstyle #build
Product: Tomcat 7
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Packaging
AssignedTo: dev@tomcat.apache.org
ReportedBy: oli...@puppycrawl.com
Created an attachment (id=26627)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=26627)
Patch to enable caching
Checkstyle supports caching files that have successfully passed with no errors,
so that these files are not processed again on subsequent invocations of
Checkstyle until the files are modified again. As the output below shows, this
speeds up the Checkstyle from 51 seconds to 15 seconds.
The attached patch, based on trunk, adds support for caching Checkstyle
results. The cache files are stored in the ${tomcat.output} directory, so are
removed whenever an "ant clean" is performed.
You could get more sophisticated and store the cache files outside of the
${tomcat.output} directory to save history across "ant clean" invocations. In
this case, you then need to make the build logic smarter to invalidate the
cache files if any of the Checkstyle configuration files change. Let me know if
you are interested in a patch to do this.
===
oliver@oliver-laptop tomcat-trunk]$ ant -q validate
[echo] Testing for /tmp/tomcat/checkstyle-5.1/checkstyle-all-5.1.jar
[checkstyle]
/home/oliver/play/tomcat-trunk/java/org/apache/catalina/tribes/group/ExtendedRpcCallback.java:21:8:
Unused import - org.apache.catalina.tribes.ErrorHandler.
BUILD FAILED
/home/oliver/play/tomcat-trunk/build.xml:430: Got 1 errors and 0 warnings.
Total time: 55 seconds
[oliver@oliver-laptop tomcat-trunk]$ ant -q validate
[echo] Testing for /tmp/tomcat/checkstyle-5.1/checkstyle-all-5.1.jar
[checkstyle]
/home/oliver/play/tomcat-trunk/java/org/apache/catalina/tribes/group/ExtendedRpcCallback.java:21:8:
Unused import - org.apache.catalina.tribes.ErrorHandler.
BUILD FAILED
/home/oliver/play/tomcat-trunk/build.xml:430: Got 1 errors and 0 warnings.
Total time: 15 seconds
--
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: Duplicate events in Lifecycle?
On 09/02/2011 09:14, Konstantin Kolinko wrote: > 1) Browsing the code in o.a.c.startup.Embedded#stopInternal() I see > the following two lines: > > fireLifecycleEvent(STOP_EVENT, null); > setState(LifecycleState.STOPPING); > > Unless I miss something it means that STOP_EVENT is fired twice, once > by the fireLifecycleEvent() call and second time by setState(). > > > 2) Lifecycle#setState() does not check that new state != old state. It > always fires a lifecycle event on every call. > > I see that some 3rd party components that extend ours (like the one > mentioned in BZ 50738) call this.setState(STARTING), then call > super.startInternal() that may fire the event second time. > > Shouldn't we avoid firing duplicate events? We should fix where we do it. 1 looks like a left-over from my refactoring. I don't think we should protect against 2. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Duplicate events in Lifecycle?
2011/2/9 Mark Thomas : > On 09/02/2011 09:14, Konstantin Kolinko wrote: >> 1) Browsing the code in o.a.c.startup.Embedded#stopInternal() I see >> the following two lines: >> >> fireLifecycleEvent(STOP_EVENT, null); >> setState(LifecycleState.STOPPING); >> >> Unless I miss something it means that STOP_EVENT is fired twice, once >> by the fireLifecycleEvent() call and second time by setState(). >> >> >> 2) Lifecycle#setState() does not check that new state != old state. It >> always fires a lifecycle event on every call. >> >> I see that some 3rd party components that extend ours (like the one >> mentioned in BZ 50738) call this.setState(STARTING), then call >> super.startInternal() that may fire the event second time. >> >> Shouldn't we avoid firing duplicate events? > > We should fix where we do it. 1 looks like a left-over from my refactoring. > > I don't think we should protect against 2. > My thought on 2 are that 1) for implementors that extend our components it might be not quite clear whether super.fooInternal() will call setState(..) or not, and the behavior of the base class may change over time 2) some LifecycleListener implementations should be better protected against repeated invocations. E.g., AprLifecycleListener#lifecycleEvent() is not protected against calling terminateAPR() twice. Maybe there are similar bugs elsewhere. 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: r1068862 - /tomcat/trunk/java/org/apache/catalina/startup/Embedded.java
Author: markt
Date: Wed Feb 9 12:26:24 2011
New Revision: 1068862
URL: http://svn.apache.org/viewvc?rev=1068862&view=rev
Log:
Prevent duplicate event messages
Modified:
tomcat/trunk/java/org/apache/catalina/startup/Embedded.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/Embedded.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Embedded.java?rev=1068862&r1=1068861&r2=1068862&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Embedded.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Embedded.java Wed Feb 9
12:26:24 2011
@@ -845,7 +845,6 @@ public class Embedded extends StandardS
if( log.isDebugEnabled() )
log.debug("Stopping embedded server");
-fireLifecycleEvent(STOP_EVENT, null);
setState(LifecycleState.STOPPING);
// Stop our defined Connectors first
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.33 Build
+1 On Feb 8, 2011, at 8:22 AM, Jim Jagielski wrote: > Retagged, rerolled and reuploaded... ;) > > On Feb 8, 2011, at 8:04 AM, Jim Jagielski wrote: > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50744] New: When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 Summary: When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work. Product: Tomcat 5 Version: 5.5.32 Platform: Other OS/Version: AIX Status: NEW Severity: major Priority: P2 Component: Servlet & JSP API AssignedTo: dev@tomcat.apache.org ReportedBy: murt...@us.ibm.com _1_) In response to CVE-2011-0013 ( and also to resolve other security issues) we decided to update Tomcat from Verion 5.5.27 to 5.5.32 _2_) The process to enable SSL for Tomcat documented at URL http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html was followed for setting up the SSL at Version 5.5.27. _2_a_) The following command was used to generate the Certificate Keystore $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA \ -keystore /home/tomcat/.keystore (However we used our customized password rather than the deafult one changeit) _2_b_) The following entry was added to server.xml : _2_c_) This process has worked correctly for serving Tomcat without SSL on port 8080 and with SSL on port 8443 _3_) Similar process was used to setup SSL for Tomcat 5.5.32. However Tomcat starts with some errors serving Tomcat on non-SSL port 8080 correctly and the SSL port on 8443 does not work. (Catalina logs have some errors and I have attached the log to this BUG report). _4_) What changed between version 5.5.27 and 5.5.32 that resulted in this failure? Thank you for your help and support in this matter. -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 Sridhar Murthy changed: What|Removed |Added Summary|When Tomcat was updated |When Tomcat was updated |from version 5.5.27 to |from version 5.5.27 to |5.5.32, SSL support for |5.5.32, SSL support for |Tomcat does not work. |Tomcat does not work on AIX ||5.3 TL-11 SP-2 -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #1 from Sridhar Murthy 2011-02-09 10:23:33 EST --- The download source for Tomcat 5.5.32 is: http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.32/bin/ The files that were downloaded are: _1_) apache-tomcat-5.5.32-compat.tar.gz 2011-01-23 20:52 1.6M _2_) apache-tomcat-5.5.32.tar.gz 2011-01-23 20:54 7.8M The chsums matched and there is no corruption of any of the binaries/files. -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 Sridhar Murthy changed: What|Removed |Added CC||murt...@us.ibm.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
svn commit: r1068989 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Author: fhanik
Date: Wed Feb 9 17:39:24 2011
New Revision: 1068989
URL: http://svn.apache.org/viewvc?rev=1068989&view=rev
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667
Move the callback outside try/catch to avoid duplicate callbacks
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068989&r1=1068988&r2=1068989&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 17:39:24 2011
@@ -158,9 +158,6 @@ public class RpcChannel implements Chann
channel.send(new Member[] {sender},
rmsg,replyMessageOptions & ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK);
}
finished = true;
-if (excallback != null && !asyncReply) {
-excallback.replySucceeded(rmsg.message, reply, sender);
-}
}catch ( Exception x ) {
if (excallback != null && !asyncReply) {
finished = !excallback.replyFailed(rmsg.message,
reply, sender, x);
@@ -169,6 +166,9 @@ public class RpcChannel implements Chann
log.error("Unable to send back reply in
RpcChannel.",x);
}
}
+if (finished && excallback != null && !asyncReply) {
+excallback.replySucceeded(rmsg.message, reply, sender);
+}
}
}//end if
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #13 from Filip Hanik 2011-02-09 12:40:16 EST --- (In reply to comment #12) > Hi Filip, > > I would have thought the second callback could be implemented in the same > class > is the (Extended)RpcCallback, but at any rate it's your call. It is, the other patch introduced a third class for callbacks that was wrapped in an error handler. I got what I > wanted out of this, so it's fine by me. cool also, the retry functionality has been removed, as it can be configured as an interceptor, or configured further down in the stack. > > A few remarks on the code: > 1. Unless I'm very much mistaken, the retry functionality won't work in async > mode. This should be documented in ExtendedRpcCallback#replyFailed. It should work in async mode, since it passes the EXRPC object into the channel as a feedback object wrapped in an error handler. > 3. The call to ExtendedRpcCallback#replySucceeded in the synchronous case > should be move outside the try/catch block. Perhaps put it in a try/catch of > its own. The way it is now, it would cause spurious behaviour if it were to > throw a RuntimeException. yes, for sure, fixed in r1068989 thanks for your feedback Filip -- 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: r1068996 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Author: fhanik
Date: Wed Feb 9 17:47:13 2011
New Revision: 1068996
URL: http://svn.apache.org/viewvc?rev=1068996&view=rev
Log:
remove loop that should not be used at all.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068996&r1=1068995&r2=1068996&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 17:47:13 2011
@@ -132,44 +132,42 @@ public class RpcChannel implements Chann
final ExtendedRpcCallback excallback = (callback instanceof
ExtendedRpcCallback)?((ExtendedRpcCallback)callback) : null;
boolean asyncReply = ((replyMessageOptions &
Channel.SEND_OPTIONS_ASYNCHRONOUS) == Channel.SEND_OPTIONS_ASYNCHRONOUS);
Serializable reply = callback.replyRequest(rmsg.message,sender);
-while (!finished) {
-ErrorHandler handler = null;
-final Serializable request = msg;
-final Serializable response = reply;
-final Member fsender = sender;
-if (excallback!=null && asyncReply) {
-handler = new ErrorHandler() {
-@Override
-public void handleError(ChannelException x, UniqueId
id) {
-excallback.replyFailed(request, response, fsender,
x);
-}
-@Override
-public void handleCompletion(UniqueId id) {
-excallback.replySucceeded(request, response,
fsender);
-}
-};
-}
-rmsg.reply = true;
-rmsg.message = reply;
-try {
-if (handler!=null) {
-channel.send(new Member[] {sender},
rmsg,replyMessageOptions & ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK, handler);
-} else {
-channel.send(new Member[] {sender},
rmsg,replyMessageOptions & ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK);
+ErrorHandler handler = null;
+final Serializable request = msg;
+final Serializable response = reply;
+final Member fsender = sender;
+if (excallback!=null && asyncReply) {
+handler = new ErrorHandler() {
+@Override
+public void handleError(ChannelException x, UniqueId id) {
+excallback.replyFailed(request, response, fsender, x);
}
-finished = true;
-}catch ( Exception x ) {
-if (excallback != null && !asyncReply) {
-finished = !excallback.replyFailed(rmsg.message,
reply, sender, x);
-} else {
-finished = true;
-log.error("Unable to send back reply in
RpcChannel.",x);
+@Override
+public void handleCompletion(UniqueId id) {
+excallback.replySucceeded(request, response, fsender);
}
+};
+}
+rmsg.reply = true;
+rmsg.message = reply;
+try {
+if (handler!=null) {
+channel.send(new Member[] {sender},
rmsg,replyMessageOptions & ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK, handler);
+} else {
+channel.send(new Member[] {sender},
rmsg,replyMessageOptions & ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK);
}
-if (finished && excallback != null && !asyncReply) {
-excallback.replySucceeded(rmsg.message, reply, sender);
+finished = true;
+}catch ( Exception x ) {
+if (excallback != null && !asyncReply) {
+finished = !excallback.replyFailed(rmsg.message, reply,
sender, x);
+} else {
+finished = true;
+log.error("Unable to send back reply in RpcChannel.",x);
}
}
+if (finished && excallback != null && !asyncReply) {
+excallback.replySucceeded(rmsg.message, reply, sender);
+}
}//end if
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1068808 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
I'm glad you commented, there should be no looping at all. It was a left over
from a previous proposal
fixed in r1068996
Filip
On 2/9/2011 2:35 AM, kkoli...@apache.org wrote:
Author: kkolinko
Date: Wed Feb 9 09:35:16 2011
New Revision: 1068808
URL: http://svn.apache.org/viewvc?rev=1068808&view=rev
Log:
Followup to r1068549 - add annotations.
I thought about moving ErrorHandler instance creation outside the retry loop,
but actually that is not needed: looping happens only when asyncReply==false
and ErrorHandler is created only when asyncReply==true. Thus it is created only
once.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068808&r1=1068807&r2=1068808&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 09:35:16 2011
@@ -139,10 +139,11 @@ public class RpcChannel implements Chann
final Member fsender = sender;
if (excallback!=null&& asyncReply) {
handler = new ErrorHandler() {
+@Override
public void handleError(ChannelException x, UniqueId
id) {
excallback.replyFailed(request, response,
fsender, x);
}
-
+@Override
public void handleCompletion(UniqueId id) {
excallback.replySucceeded(request, response,
fsender);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3431 - Release Date: 02/08/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1069016 - /tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
Author: markt
Date: Wed Feb 9 18:25:48 2011
New Revision: 1069016
URL: http://svn.apache.org/viewvc?rev=1069016&view=rev
Log:
Better comments
Modified:
tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
Modified: tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java?rev=1069016&r1=1069015&r2=1069016&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java Wed Feb 9
18:25:48 2011
@@ -164,13 +164,9 @@ public abstract class LifecycleBase impl
/**
- * Sub-classes must ensure that:
- *
- * the {@link Lifecycle#START_EVENT} is fired during the execution of
- * this method
- * the state is changed to {@link LifecycleState#STARTING} when the
- * {@link Lifecycle#START_EVENT} is fired
- *
+ * Sub-classes must ensure that the state is changed to
+ * {@link LifecycleState#STARTING} during the execution of this method.
+ * Changing state will trigger the {@link Lifecycle#START_EVENT} event.
*
* If a component fails to start it may either throw a
* {@link LifecycleException} which will cause it's parent to fail to start
@@ -243,13 +239,9 @@ public abstract class LifecycleBase impl
/**
- * Sub-classes must ensure that:
- *
- * the {@link Lifecycle#STOP_EVENT} is fired during the execution of
- * this method
- * the state is changed to {@link LifecycleState#STOPPING} when the
- * {@link Lifecycle#STOP_EVENT} is fired
- *
+ * Sub-classes must ensure that the state is changed to
+ * {@link LifecycleState#STOPPING} during the execution of this method.
+ * Changing state will trigger the {@link Lifecycle#STOP_EVENT} event.
*
* @throws LifecycleException
*/
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #2 from Konstantin Kolinko 2011-02-09 13:26:54 EST --- (In reply to comment #0) > Catalina logs have some errors and I have attached the log to this BUG > report). There is no attachment. Without seeing the actual error it is hard to help. -- 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: Duplicate events in Lifecycle?
On 09/02/2011 11:32, Konstantin Kolinko wrote: > 2011/2/9 Mark Thomas : >> On 09/02/2011 09:14, Konstantin Kolinko wrote: >>> 1) Browsing the code in o.a.c.startup.Embedded#stopInternal() I see >>> the following two lines: >>> >>> fireLifecycleEvent(STOP_EVENT, null); >>> setState(LifecycleState.STOPPING); >>> >>> Unless I miss something it means that STOP_EVENT is fired twice, once >>> by the fireLifecycleEvent() call and second time by setState(). >>> >>> >>> 2) Lifecycle#setState() does not check that new state != old state. It >>> always fires a lifecycle event on every call. >>> >>> I see that some 3rd party components that extend ours (like the one >>> mentioned in BZ 50738) call this.setState(STARTING), then call >>> super.startInternal() that may fire the event second time. >>> >>> Shouldn't we avoid firing duplicate events? >> >> We should fix where we do it. 1 looks like a left-over from my refactoring. >> >> I don't think we should protect against 2. >> > > My thought on 2 are that > 1) for implementors that extend our components it might be not quite > clear whether super.fooInternal() will call setState(..) or not, and > the behavior of the base class may change over time Logically the first concrete implementation is going to have to meet the requirements for the fooInternal() methods so it is always the case that a super class will have taken care of this. I have tweaked the docs because they suggested setting state and firing the event were separate tasks which is not the case. Further doc improvements welcome. > 2) some LifecycleListener implementations should be better protected > against repeated invocations. E.g., > AprLifecycleListener#lifecycleEvent() is not protected against calling > terminateAPR() twice. Maybe there are similar bugs elsewhere. Hmm. I'm pretty sure I looked at enforcing the state change rules in setState() previously but decided not to for some reason I can't remember. I'll take another look as that may have been mid-refactoring. It certainly looks doable after a quick glance at the current code. That will make it much more robust against mis-use. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 Christopher Schultz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Christopher Schultz 2011-02-09 13:43:52 EST --- You are going to provide some more information. This isn't a bug report: it's a request for help. Please post to the user list before filing a bug. If this is determined to be a bug, please re-open. -- 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: r1069032 - /tomcat/trunk/java/org/apache/catalina/Lifecycle.java
Author: markt Date: Wed Feb 9 19:01:20 2011 New Revision: 1069032 URL: http://svn.apache.org/viewvc?rev=1069032&view=rev Log: add some arrows to the diagram Modified: tomcat/trunk/java/org/apache/catalina/Lifecycle.java Modified: tomcat/trunk/java/org/apache/catalina/Lifecycle.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Lifecycle.java?rev=1069032&r1=1069031&r2=1069032&view=diff == --- tomcat/trunk/java/org/apache/catalina/Lifecycle.java (original) +++ tomcat/trunk/java/org/apache/catalina/Lifecycle.java Wed Feb 9 19:01:20 2011 @@ -31,7 +31,7 @@ package org.apache.catalina; * NEW ->-- INITIALIZING * ||| | <--- * ||| |auto | | - * ||| | start() |auto auto stop() | + * ||| \|/start() \|/ auto auto stop() | * ||| INITIALIZED -->-- STARTING_PREP -->- STARTING -->- STARTED -->--- | * ||| ^ | | | * |||start() | | | | @@ -42,7 +42,7 @@ package org.apache.catalina; * | | | | | * | | ---< ^ * | | | | - * | | | auto auto start() | + * | | \|/auto auto start() | * | | STOPPING_PREP -->- STOPPING -->- STOPPED >-- * | | ^ | | ^ * | | | auto | | | - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #4 from Sridhar Murthy 2011-02-09 14:02:44 EST --- Created an attachment (id=26628) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26628) Catalina Log -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 Sridhar Murthy changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #5 from Sridhar Murthy 2011-02-09 14:14:21 EST --- I personally think that it is not a help request. We had a server.xml file working for both SSL port and Non-SSL port for Tomcat Version 5.5.27 We updated the Tomcat to Version 5.5.32 and used the same server.xml file. With that the SSL port of Tomcat stopped working. The O/S and all the other things have remained the same on the server on which Tomcat update was performed and that leads me to believe that something changed in Tomcat that caused the failure. I have upload the catalina log for your perusal. Kindly review the log and let me know if in fact it is a configuartion issue and I need to pursue it with user group. Thank you for your help and support in this matter. -- 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 50747] New: CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747
Summary: CometProcessor does not flush and close HTTP/1.0
requests
Product: Tomcat 7
Version: 7.0.8
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: frank.schroe...@gmail.com
I have built a simple Publish/Subscribe servlet using the CometProcessor. When
a client connects then the servlet checks in the BEGIN phase whether there are
pending events for the client and if not stores the request in a list of
pending requests. Later another thread notifies the CometProcessor that data
for the user has arrived and the data is pushed through the pending connection.
The pseudo-code looks like this:
public class EventService implements CometProcessor {
public void event(CometEvent event) {
if (event.getType() == CometEvent.BEGIN) {
String data = getDataForUser(event);
if (data != null) {
sendAndClose(data, event);
} else {
pendingRequests.add(event);
}
} else {
event.close();
}
}
public void push(String user, String data) {
CometEvent event = findPendingRequest(user);
sendAndClose(data, event);
pendingRequests.remove(event);
}
public void sendAndClose(String data, CometEvent event) {
Writer w = event.request.getWriter();
w.write(data);
w.flush();
event.close();
}
}
This works as expected as long as I connect with an HTTP/1.1 client. However,
when an HTTP/1.0 client connects (e.g. nginx) the connection is not closed
immediately. In my case the data is a JSON string which is pushed to the client
if the client ends with '\r\n' but the connection lingers open.
This is also reproducible with curl
HTTP/1.1 request
# curl -v -XGET -u 'frank:frank'
'http://127.0.0.1:8081/fcc/event?timestamp=1297277309368'; echo
> GET /fcc/event?timestamp=1297277309368 HTTP/1.1
> Authorization: Basic xxx
> User-Agent: curl/7.21.2 ...
> Host: 127.0.0.1:8081
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/json;charset=ISO-8859-1
< Transfer-Encoding: chunked
< Date: Wed, 09 Feb 2011 18:49:45 GMT
<
{"type":"settings-changed","timestamp":1297277385366,"data":{"version":157}}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
^^^
Connection is closed immediately
HTTP/1.0 request
# curl -v -XGET -0 -u 'frank:xxx'
'http://127.0.0.1:8081/fcc/event?timestamp=1297277309368'; echo
> GET /fcc/event?timestamp=1297277309368 HTTP/1.0
> Authorization: Basic xxx
> User-Agent: curl/7.21.2 ...
> Host: 127.0.0.1:8081
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/json;charset=ISO-8859-1
< Date: Wed, 09 Feb 2011 18:49:45 GMT
< Connection: close
<
{"type":"settings-changed","timestamp":1297277385366,"data":{"version":157}}
^^^
Connection stays open until timeout occurs
--
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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #6 from Konstantin Kolinko 2011-02-09 14:23:42 EST --- >From the log: Feb 8, 2011 8:40:32 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Feb 8, 2011 8:40:34 PM org.apache.coyote.http11.Http11BaseProtocol init SEVERE: Error initializing endpoint java.net.SocketException: Unbound server sockets not implemented at javax.net.ServerSocketFactory.createServerSocket(Unknown Source) at org.apache.tomcat.util.compat.Jdk14Compat.getUnboundSocket(Jdk14Compat.java:130) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.checkConfig(JSSESocketFactory.java:393) at org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.init(JSSE14SocketFactory.java:127) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:96) at org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:293) at org.apache.coyote.http11.Http11BaseProtocol.init(Http11BaseProtocol.java:139) at org.apache.catalina.connector.Connector.initialize(Connector.java:1002) (...) -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #7 from Sridhar Murthy 2011-02-09 14:26:44 EST --- Created an attachment (id=26629) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26629) This server.xml works correctly for both SSL and non-SSL port for Tomcat 5.5.27 and fails to serve Tomcat on SSL port for Tomcat 5.5.32 Sumitting the server.xml file that works correctly for both SSL and non-SSL port for Tomcat 5.5.27 and fails to serve Tomcat on SSL port for Tomcat 5.5.32. If Tomcat 5.5.32 is working correctly then should the server.xml that I have attached work corrctly (which worked as per the design on Tomcat 5.5.27) ? -- 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: r1069056 - in /tomcat/trunk: java/org/apache/catalina/connector/MapperListener.java java/org/apache/catalina/util/LifecycleBase.java webapps/docs/changelog.xml
Author: markt
Date: Wed Feb 9 19:46:49 2011
New Revision: 1069056
URL: http://svn.apache.org/viewvc?rev=1069056&view=rev
Log:
Add further checks that LifecycleBase sub-classes are correctly changing state.
Modified:
tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java
tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java?rev=1069056&r1=1069055&r2=1069056&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/MapperListener.java Wed Feb
9 19:46:49 2011
@@ -24,6 +24,7 @@ import org.apache.catalina.Engine;
import org.apache.catalina.Host;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
+import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.LifecycleState;
import org.apache.catalina.Wrapper;
@@ -92,7 +93,7 @@ public class MapperListener extends Life
// --- Lifecycle
Methods
@Override
-public void startInternal() {
+public void startInternal() throws LifecycleException {
setState(LifecycleState.STARTING);
@@ -116,7 +117,7 @@ public class MapperListener extends Life
@Override
-public void stopInternal() {
+public void stopInternal() throws LifecycleException {
setState(LifecycleState.STOPPING);
}
Modified: tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java?rev=1069056&r1=1069055&r2=1069056&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java (original)
+++ tomcat/trunk/java/org/apache/catalina/util/LifecycleBase.java Wed Feb 9
19:46:49 2011
@@ -95,16 +95,16 @@ public abstract class LifecycleBase impl
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
-setState(LifecycleState.INITIALIZING);
+setStateInternal(LifecycleState.INITIALIZING, null, false);
try {
initInternal();
} catch (LifecycleException e) {
-setState(LifecycleState.FAILED);
+setStateInternal(LifecycleState.FAILED, null, false);
throw e;
}
-setState(LifecycleState.INITIALIZED);
+setStateInternal(LifecycleState.INITIALIZED, null, false);
}
@@ -139,12 +139,12 @@ public abstract class LifecycleBase impl
invalidTransition(Lifecycle.BEFORE_START_EVENT);
}
-setState(LifecycleState.STARTING_PREP);
+setStateInternal(LifecycleState.STARTING_PREP, null, false);
try {
startInternal();
} catch (LifecycleException e) {
-setState(LifecycleState.FAILED);
+setStateInternal(LifecycleState.FAILED, null, false);
throw e;
}
@@ -158,7 +158,7 @@ public abstract class LifecycleBase impl
invalidTransition(Lifecycle.AFTER_START_EVENT);
}
-setState(LifecycleState.STARTED);
+setStateInternal(LifecycleState.STARTED, null, false);
}
}
@@ -212,18 +212,18 @@ public abstract class LifecycleBase impl
invalidTransition(Lifecycle.BEFORE_STOP_EVENT);
}
-setState(LifecycleState.STOPPING_PREP);
+setStateInternal(LifecycleState.STOPPING_PREP, null, false);
try {
stopInternal();
} catch (LifecycleException e) {
-setState(LifecycleState.FAILED);
+setStateInternal(LifecycleState.FAILED, null, false);
throw e;
}
if (state.equals(LifecycleState.MUST_DESTROY)) {
// Complete stop process first
-setState(LifecycleState.STOPPED);
+setStateInternal(LifecycleState.STOPPED, null, false);
destroy();
} else {
@@ -233,7 +233,7 @@ public abstract class LifecycleBase impl
invalidTransition(Lifecycle.AFTER_STOP_EVENT);
}
-setState(LifecycleState.STOPPED);
+setStateInternal(LifecycleState.STOPPED, null, false);
}
}
@@ -271,16 +271,16 @@ public abstract class LifecycleBase impl
invalidTransition(Lifecycle.BEFORE_DESTROY_EVENT);
}
-setState(LifecycleState.DESTROYING);
+setStateInternal(LifecycleState.DESTROYING, null, false);
t
svn commit: r1069060 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Wed Feb 9 19:50:37 2011 New Revision: 1069060 URL: http://svn.apache.org/viewvc?rev=1069060&view=rev Log: Correct the package name Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1069060&r1=1069059&r2=1069060&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Feb 9 19:50:37 2011 @@ -60,8 +60,8 @@ Add additional checks to ensure that sub-classes of -org.apache.catalina.LifecycleBase correctly implement the -expected state transitions. (markt) +org.apache.catalina.util.LifecycleBase correctly implement +the expected state transitions. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747
Frank Schroeder changed:
What|Removed |Added
OS/Version||All
--- Comment #1 from Frank Schroeder 2011-02-09
15:21:54 EST ---
I've found the problem. The following sequence works with HTTP/1.1 but not with
HTTP/1.0. I guess I've made a classical optimization mistake. This also
explains why the content length and encoding headers were never set.
String data = "...";
PrintWriter writer = response.getWriter();
response.setStatus(200);
response.setCharacterEncoding("UTF-8");
response.setContentLength(data.length());
writer.write(data);
writer.flush();
event.close();
Getting the Writer *after* setting the response headers makes it all work
String data = "...";
response.setStatus(200);
response.setCharacterEncoding("UTF-8");
response.setContentLength(data.length());
PrintWriter writer = response.getWriter();
writer.write(data);
writer.flush();
event.close();
--
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 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747
--- Comment #2 from Konstantin Kolinko 2011-02-09
15:39:00 EST ---
> String data = "...";
> response.setCharacterEncoding("UTF-8");
> response.setContentLength(data.length());
> PrintWriter writer = response.getWriter();
The above code is wrong, because String.length() is measured in chars, but
content-length header is measured in bytes. UTF-8 uses more than 1 byte for
characters > 127.
--
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 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747 --- Comment #3 from Mark Thomas 2011-02-09 15:48:04 EST --- Tomcat could be a little smarter here. We currently ignore a call to setContentLength() after a call to getWriter(). However, we only have to ignore the content length once bytes have actually been written to the response and a method to determine that is available. If I were to patch trunk, could you build 7.0.x from source and give it a try? -- 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 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747
--- Comment #4 from Frank Schroeder 2011-02-09
15:55:29 EST ---
Sure, I can try that. While you're at it you can also check the encoding as it
wasn't set as well. The content type was OK. The reason I had this code was
because of this:
PrintWriter writer = response.getWriter();
if (jsonp) {
String data = ... build jsonp here ...
response.setStatus(200);
response.setContentType("text/javascript");
response.setCharacterEncoding("UTF-8");
response.setContentLength(data.length());
writer.write(data);
} else {
String data = ... build json here ...
response.setStatus(200);
response.setContentType("application/json");
response.setCharacterEncoding("UTF-8");
response.setContentLength(data.length());
writer.write(data);
}
writer.flush();
event.close();
Regarding the content length. So I guess that should be then like this?
response.setContentLength(data.getBytes("UTF-8").length);
As a side node and for completeness:
nginx still hung but turning off proxy buffering with
proxy_buffering off;
fixed that as well.
--
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 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747 --- Comment #5 from Mark Thomas 2011-02-09 16:16:04 EST --- You can't change the encoding once the writer has been obtained since the encoding is used to create the writer. -- 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 50748] New: Ignoring setContentLength( ) when using writer is incomplete
https://issues.apache.org/bugzilla/show_bug.cgi?id=50748 Summary: Ignoring setContentLength( ) when using writer is incomplete Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: knst.koli...@gmail.com Reviewing o.a.c.connector.Response after comments in https://issues.apache.org/bugzilla/show_bug.cgi?id=50747#c3 In o.a.c.connector.Response there is a feature that Response#setContentLength(int) ignores the call if usingWriter flag is true. My comments are: 1) It concerns only multi-byte charsets such as UTF-8. There is nothing wrong with calling setContentLength() if it is a single-byte charset. 2) There is no such protection in Response#setHeader(), #setIntHeader(), #addHeader(), #addIntHeader() methods. Calling them will bypass the protection. See how o.a.coyote.Response implements those methods and o.a.coyote.Response#checkSpecialHeader() for comparison. -- 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 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747
--- Comment #6 from Konstantin Kolinko 2011-02-09
16:54:08 EST ---
(In reply to comment #3)
> Tomcat could be a little smarter here.
For reference: I filed bug 50748 to deal with setContentLength() improvements.
(In reply to comment #4)
> Regarding the content length. So I guess that should be then like this?
> response.setContentLength(data.getBytes("UTF-8").length);
>
If you already called getBytes() then use byte[] array that it returns and pass
to an OutputStream. You won't need a Writer. There is no need to do the double
work.
--
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: r1069131 - in /tomcat/trunk: java/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml
Author: markt Date: Wed Feb 9 21:56:14 2011 New Revision: 1069131 URL: http://svn.apache.org/viewvc?rev=1069131&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50747 Allow the content length header to be set up to the point the response is committed when a writer is used. Modified: tomcat/trunk/java/org/apache/catalina/connector/Response.java tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/java/org/apache/catalina/connector/Response.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Response.java?rev=1069131&r1=1069130&r2=1069131&view=diff == --- tomcat/trunk/java/org/apache/catalina/connector/Response.java (original) +++ tomcat/trunk/java/org/apache/catalina/connector/Response.java Wed Feb 9 21:56:14 2011 @@ -756,9 +756,6 @@ public class Response if (included) return; -if (usingWriter) -return; - coyoteResponse.setContentLength(length); } Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1069131&r1=1069130&r2=1069131&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Feb 9 21:56:14 2011 @@ -63,6 +63,10 @@ org.apache.catalina.util.LifecycleBase correctly implement the expected state transitions. (markt) + +50747: Allow the content length header to be set up to the +point the response is committed when a writer is beng used. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1069135 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Wed Feb 9 22:00:08 2011 New Revision: 1069135 URL: http://svn.apache.org/viewvc?rev=1069135&view=rev Log: The bug number changed Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1069135&r1=1069134&r2=1069135&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Feb 9 22:00:08 2011 @@ -64,7 +64,7 @@ the expected state transitions. (markt) -50747: Allow the content length header to be set up to the +50748: Allow the content length header to be set up to the point the response is committed when a writer is beng used. (markt) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50747] CometProcessor does not flush and close HTTP/1.0 requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=50747 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Mark Thomas 2011-02-09 17:19:51 EST --- This issue is part useful discussion, part bug. The bug part has moved to 50748 and the discussion should move to the users mailing list. *** This bug has been marked as a duplicate of bug 50748 *** -- 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 50748] Ignoring setContentLength( ) when using writer is incomplete
https://issues.apache.org/bugzilla/show_bug.cgi?id=50748 Mark Thomas changed: What|Removed |Added CC||frank.schroe...@gmail.com --- Comment #1 from Mark Thomas 2011-02-09 17:19:52 EST --- *** Bug 50747 has been marked as a duplicate of this bug. *** -- 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 50748] Ignoring setContentLength( ) when using writer is incomplete
https://issues.apache.org/bugzilla/show_bug.cgi?id=50748 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas 2011-02-09 17:40:44 EST --- This fixed in 7.0.x and will be included in 7.0.9 onwards. Both single and multi-byte encodings are handled since OutputBuffer.close() sets the content-length to the number of bytes, not the number of characters. I suspect the test in the response dates from a time when content length was set using characters although I haven't done the code archeology to be sure of that. -- 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: r1069166 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Author: markt
Date: Wed Feb 9 23:13:00 2011
New Revision: 1069166
URL: http://svn.apache.org/viewvc?rev=1069166&view=rev
Log:
Ensure NamingResources follows correct lifecycle
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1069166&r1=1069165&r2=1069166&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Wed Feb 9
23:13:00 2011
@@ -1944,6 +1944,7 @@ public class StandardContext extends Con
if (getState() != LifecycleState.NEW) {
if (oldNamingResources != null) {
try {
+oldNamingResources.stop();
oldNamingResources.destroy();
} catch (LifecycleException e) {
log.warn("standardContext.namingResource.destroy.fail", e);
@@ -1952,6 +1953,7 @@ public class StandardContext extends Con
if (namingResources != null) {
try {
namingResources.init();
+namingResources.start();
} catch (LifecycleException e) {
log.warn("standardContext.namingResource.init.fail", e);
}
@@ -4880,6 +4882,12 @@ public class StandardContext extends Con
setConfigured(false);
boolean ok = true;
+// Currently this is effectively a NO-OP but needs to be called to
+// ensure the NamingResources follows the correct lifecycle
+if (namingResources != null) {
+namingResources.start();
+}
+
// Add missing components as necessary
if (webappResources == null) { // (1) Required by Loader
if (log.isDebugEnabled())
@@ -5303,6 +5311,12 @@ public class StandardContext extends Con
setState(LifecycleState.STOPPING);
+// Currently this is effectively a NO-OP but needs to be called to
+// ensure the NamingResources follows the correct lifecycle
+if (namingResources != null) {
+namingResources.stop();
+}
+
// Binding thread
ClassLoader oldCCL = bindThread();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1069170 - in /tomcat/trunk: java/org/apache/catalina/util/RequestUtil.java test/org/apache/catalina/util/TestRequestUtil.java webapps/docs/changelog.xml
Author: markt
Date: Wed Feb 9 23:41:32 2011
New Revision: 1069170
URL: http://svn.apache.org/viewvc?rev=1069170&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50721
Correctly handle URL decoding where the URL ends in %nn.
Patch (for fix) provided by Christof Marti.
Additional test cases added.
Modified:
tomcat/trunk/java/org/apache/catalina/util/RequestUtil.java
tomcat/trunk/test/org/apache/catalina/util/TestRequestUtil.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/util/RequestUtil.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/RequestUtil.java?rev=1069170&r1=1069169&r2=1069170&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/RequestUtil.java (original)
+++ tomcat/trunk/java/org/apache/catalina/util/RequestUtil.java Wed Feb 9
23:41:32 2011
@@ -326,7 +326,7 @@ public final class RequestUtil {
if (b == '+' && isQuery) {
b = (byte)' ';
} else if (b == '%') {
-if (ix + 2 >= len) {
+if (ix + 2 > len) {
throw new IllegalArgumentException(
sm.getString("requestUtil.urlDecode.missingDigit"));
}
Modified: tomcat/trunk/test/org/apache/catalina/util/TestRequestUtil.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/util/TestRequestUtil.java?rev=1069170&r1=1069169&r2=1069170&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/util/TestRequestUtil.java (original)
+++ tomcat/trunk/test/org/apache/catalina/util/TestRequestUtil.java Wed Feb 9
23:41:32 2011
@@ -28,7 +28,7 @@ public class TestRequestUtil extends Tes
assertEquals("/",RequestUtil.normalize("//"));
}
-public void testURLDecodeString() {
+public void testURLDecodeStringInvalid() {
// %n rather than %nn should throw an IAE according to the Javadoc
Exception exception = null;
try {
@@ -47,4 +47,40 @@ public class TestRequestUtil extends Tes
}
assertTrue(exception instanceof IllegalArgumentException);
}
+
+public void testURLDecodeStringValidIso88591Start() {
+
+String result = RequestUtil.URLDecode("%41", "ISO-8859-1");
+assertEquals("A", result);
+}
+
+public void testURLDecodeStringValidIso88591Middle() {
+
+String result = RequestUtil.URLDecode("xx%41xx", "ISO-8859-1");
+assertEquals("xxAxx", result);
+}
+
+public void testURLDecodeStringValidIso88591End() {
+
+String result = RequestUtil.URLDecode("%41", "ISO-8859-1");
+assertEquals("A", result);
+}
+
+public void testURLDecodeStringValidUtf8Start() {
+String result = RequestUtil.URLDecode("%c3%aa", "UTF-8");
+assertEquals("\u00ea", result);
+}
+
+public void testURLDecodeStringValidUtf8Middle() {
+
+String result = RequestUtil.URLDecode("xx%c3%aaxx", "UTF-8");
+assertEquals("xx\u00eaxx", result);
+}
+
+public void testURLDecodeStringValidUtf8End() {
+
+String result = RequestUtil.URLDecode("%c3%aa", "UTF-8");
+assertEquals("\u00ea", result);
+}
+
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1069170&r1=1069169&r2=1069170&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Feb 9 23:41:32 2011
@@ -64,8 +64,12 @@
the expected state transitions. (markt)
+50721: Correctly handle URL decoding where the URL ends in
+%nn. Patch provided by Christof Marti. (markt)
+
+
50748: Allow the content length header to be set up to the
-point the response is committed when a writer is beng used. (markt)
+point the response is committed when a writer is being used. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50721] RequestUtil.URLDecode() throws IllegalArgumentException for URLs with %xx-Code as last character
https://issues.apache.org/bugzilla/show_bug.cgi?id=50721 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas 2011-02-09 18:42:43 EST --- Thanks for the report. This has been fixed in 7.0.x and will be in 7.0.9 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
DO NOT REPLY [Bug 48717] Session listeners not called on cluster node start
https://issues.apache.org/bugzilla/show_bug.cgi?id=48717 David Rees changed: What|Removed |Added Status|RESOLVED|REOPENED Version|5.5.28 |5.5.32 Resolution|FIXED | --- Comment #6 from David Rees 2011-02-09 19:29:32 EST --- I never got a chance to test that this was fixed until now, but testing on 5.5.32 still does not appear to work. How I'm testing: Two Linux systems running Tomcat 5.5.32 with a Cluster defined in the Host section like this: The application has a defined in the web.xml which implements ServletContextListener and HttpSessionListener. The HttpSessionListener methods work fine on each node. The application adds an attribute to a session which implements HttpSessionActivationListener, HttpSessionBindingListener and Serializable. The HttpSessionBindingListener methods work fine on each node. When restarting a node, the session attribute never receives any calls to sessionDidActivate when that node comes back online. Let me know if you need any more details. -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #8 from Sridhar Murthy 2011-02-09 20:54:40 EST --- Hi Konstantin: If all the configuartions required for the Tomcat to start services on both SSL port ( 8443) and non-SSL port (8080) are put in place in server.xml and when Tomcat server is started the services on port 8443 are not started with Tomcat 5.5.32 Here is the deal: root@svmciqa002 $ netstat -an | grep 8443 root@svmciqa002 $ netstat -an | grep 8080 tcp0 0 *.8080 *.*LISTEN root@svmciqa002 $ I configure Tomcat 5.5.27 and use the same server.xml that was used for 5.5.32. Guess what - both ports (8443 and 8080) are listening as per the design: root@svmciqa002 $ netstat -an | grep 8443 tcp0 0 *.8443 *.*LISTEN root@svmciqa002 $ netstat -an | grep 8080 tcp0 0 *.8080 *.*LISTEN root@svmciqa002 $ I disagree with your argument that I have incorrect syntax with my server.xml file. If what you suspect is true, then I would not see the services on port 8443 for both Tomcat Versions (5.5.27 as well as 5.5.32) Kindly get back to me with your thoughts on this. Thank you for your help and support in this matter. Sri -- 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 50744] When Tomcat was updated from version 5.5.27 to 5.5.32, SSL support for Tomcat does not work on AIX 5.3 TL-11 SP-2
https://issues.apache.org/bugzilla/show_bug.cgi?id=50744 --- Comment #9 from Konstantin Kolinko 2011-02-09 21:30:57 EST --- Created an attachment (id=26630) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26630) 2011-02-11_tc55_50744_JSSESocketFactory.patch (In reply to comment #8) > I disagree with your argument that I have incorrect syntax with my server.xml > file. Whom do you disagree with? I never said the above. The issue here is that the 1.4 JVM that you are using does not implement a feature of "unbound server sockets" that the current code uses. Looking at Jdk14Compat.java that probably stems from http://svn.apache.org/viewvc?view=revision&revision=778258 that apparently is a fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=45528 which is about 1,5 years ago. I am attaching a patch (for the current tc5.5.x, as of 5.5.33) that will probably fix this issue. -- 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
