DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35746 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 00:41 --- While I agree with the general centiment that if an alternative algorithm works in more cases with no loss of performance that your idea maybe sound. But the following statement demonstrates your limited knowledge of what NTP goals are. (In reply to comment #4) Whenever a user (or the ntp update agent/service/deamon) sets the date/time, sessions may be lost. An NTP client does not reset the clock when it computes a variation. It makes the system clock tick faster or slower to narrow that variation over time. If its too far out NTP will not function and abort. Since TC is not a realtime application and runs largely on a multitaking OS a faster/slower clock is not ordinarly detectable by an appliction. Which is the point of running NTP. I'm a great believer that just as time never goes backwards that clock slew is not something that an application programmer has to deal with. This is one certainty of the universe for which computer concepts live within so as such its an underpins everything. If you want to change the time then do so in the BIOS before the operating system boots up, of the user changes the time force a device reboot. If the application of the device means you dont want this then you've going to have to look at NTP anyway. Some would argue that short sighted embeded device creators didn't provision an adequate mechanism to change the clock or keep it up-to-date. Since its a given that the accuracy of the clock source in the device while good isn't perfect (like most things) and the device's software relies heavily on absolute time to function. One question on your algorithm, is it written in the Java specification for the Thread.sleep() function that this has to be implmented in a way impervious to clock slew ? Or does that claim come from your experiments with a particular JVM implementation on the particular embeded device you have to hand ? It is no good building castles in the sand. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34956] - Tomcat should enforce the requirements from servlet 2.4 specification SRV.8.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34956. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34956 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 03:12 --- If you add support for this feature, don't forget to use Globals.STRICT_SERVLET_COMPLIANCE, because besides annoying some people, this won't have any real value. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451742 - in /tomcat/site/trunk: docs/download-connectors.html xdocs/download-connectors.xml
Author: rjung Date: Sun Oct 1 05:19:01 2006 New Revision: 451742 URL: http://svn.apache.org/viewvc?view=revrev=451742 Log: Update download version for mod_jk from 1.2.18 to 1.2.19. I did this already on the web site as part of the release process, but forgot to update the svn sources for the web site :( Modified: tomcat/site/trunk/docs/download-connectors.html tomcat/site/trunk/xdocs/download-connectors.xml Modified: tomcat/site/trunk/docs/download-connectors.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-connectors.html?view=diffrev=451742r1=451741r2=451742 == --- tomcat/site/trunk/docs/download-connectors.html (original) +++ tomcat/site/trunk/docs/download-connectors.html Sun Oct 1 05:19:01 2006 @@ -218,18 +218,18 @@ /div ul li class=download -a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.tar.gzJK 1.2.18 Source Release tar.gz/a +a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gzJK 1.2.19 Source Release tar.gz/a ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.tar.gz.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gz.asc;pgp/a]/span /li /ul /li li class=download -a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.zipJK 1.2.18 Source Release zip/a +a href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.zipJK 1.2.19 Source Release zip/a ul class=attributes li -span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.zip.asc;pgp/a]/span +span class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.zip.asc;pgp/a]/span /li /ul /li Modified: tomcat/site/trunk/xdocs/download-connectors.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/download-connectors.xml?view=diffrev=451742r1=451741r2=451742 == --- tomcat/site/trunk/xdocs/download-connectors.xml (original) +++ tomcat/site/trunk/xdocs/download-connectors.xml Sun Oct 1 05:19:01 2006 @@ -29,13 +29,13 @@ div class=linksspan class=labelJK 1.2 (bactively maintained/b)/span/div ulli class=group div class=linksspan class=labelSource/span/div -ulli class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.tar.gzJK 1.2.18 Source Release tar.gz/a -ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.tar.gz.asc;pgp/a]/span +ulli class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gzJK 1.2.19 Source Release tar.gz/a +ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.tar.gz.asc;pgp/a]/span /li /ul /li -li class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.zipJK 1.2.18 Source Release zip/a -ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.18/tomcat-connectors-1.2.18-src.zip.asc;pgp/a]/span +li class=downloada href=[preferred]/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.zipJK 1.2.19 Source Release zip/a +ul class=attributeslispan class=pgp[a href=http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.19/tomcat-connectors-1.2.19-src.zip.asc;pgp/a]/span /li /ul /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35746 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 05:42 --- The point is not about NTP. The point is that on systems where time can be set by the user, sessions could be lost. Going into the bios is not an option for servers in a remote datacenter. Embeded systems and appliance do not expose the boot swequence nor the bios. Assume the system we are talking about here is offering the user the option to set time. I just wanted to share my experience and provide a resilient session expiration mecanism. - - - Notes on ntp: NTP agents can either accellerate, decellerate or set the clock, depending on how you configure it. If you try to rewind time by an hour, it would take minimum 1 hour assuming the clock can literally stop. In most case this is not acceptable. If you wanted to advance clock by 1 hour while time could accelerate to 2x, you would still need 1 hour to do so, and the device would be taxed by having to do all its scheduled jobs twice as much with the same hardware. From an other angle, the hardware is effectively 2x slower. For example, thinks about backups, scheduled purges, mailouts, etc... I know very well the effect of time warping, we wrote a kernel module to simulate weeks of uptime in a few hours (ex: for 100x speed, simply add 100 jiffies instead of 1). Note that this does shorten the actual duration of sleep() and wait(), which is why it worked for our long uptime simulations (the entire linux kernel relies on that time we tweak). However, I don't know if NTP updates are playing with jiffies or if the sleep()/wait() would be unaffected. What I do know, is that you can write a simple java program that just sleep(6) and while it sleeps, you can set (not drift) the time all you want, there is no forcing sleep() to last shorter nor longer. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35746.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35746
--- Additional Comments From [EMAIL PROTECTED] 2006-10-01 07:42 ---
(In reply to comment #6)
What I do know, is that you can write a simple java program that just
sleep(6) and while it sleeps, you can set (not drift) the time all you
want,
there is no forcing sleep() to last shorter nor longer.
To reconfirm my opening comment, if your proposal makes thing work in more cases
without any side-effects or performance impact I can't see any objection for it.
Maybe you could confirm this is the case once you work out a patch.
But to be clear you're not able to cite any contractual Java API requirement
that Thread.sleep() must always work the way you describe on all JVMs on all
operating systems. You can only say it works in the case you tested.
The bigger question here is that you are fixing only one issue where comparisons
to absolute system time are being made, how many other parts of the code are
affected to. Should a complex application (like TC) be expected to deal with
time going backwards (it is a given that applications can already deal
gracefully with time going forwards).
Thinking down the road towards a solution:
Let suppose you were able to detect a slew occur, and calculate how much slew
occured.
The session expiry may not be the only place affected, you might also need to
modify the code which accesses a session (if that code is doing an expiry check
on every access). Everytime a session is accessed a clock slew detection
algorithm would need to detect slew. if(currentTime session.lastAccessedTime
|| currentTime (session.lastAccessedTime + expiryIntervalTime +
miniLatencyMargin)) { sessionFixSlew(); } Maybe that works providing the
expiryIntervalTime is less than half the session timeout. Maybe that works
providing you dont care about slew of less than expiryIntervalTime not being
detectable.
Maybe the solution calls for a custom StandardSession implementation.
As for your other comments..
I disagree with your x0.5 through x2 values, sure its theoretically possible to
do but who is doing it ? Maybe x0.98 to x1.02 is more realistic value to cite.
I disagree with your datacentre argument, on some unix the clock tool allow
setting of BIOS clock without needing to go into the BIOS. It pretty obvious to
me how the construct a mechanism in an embeded device to change the clock you
either do it last thing just before issuing a hardware reset (as part of the
procedure to change the clock) or you store a +/- modification value in some
non-volatile place and just as the OS boots up it make the correction. A bit
like the old /etc/ntp.drift file.
Implementing RTC updating, kernel adjtimex support and a basic NTP client are
substantially less work than implementing a JVM and if an embeded device has
resources to run a JVM (and tomcat inside that) then we're not talking about no
microPU for a washing machine are we.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35746 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 07:56 --- (In reply to comment #5) But the following statement demonstrates your limited knowledge of what NTP goals are. An NTP client does not reset the clock when it computes a variation. It makes the system clock tick faster or slower to narrow that variation over time. If its too far out NTP will not function and abort. Since you know so much about how all implementations of NTP operate, perhaps you can explain to me how a datacenter I know of had all of their clocks jump forward by five minutes, then a couple hours later jump backwards by five minutes, and then repeat a couple more times over the next few days. This was under Windows, and was caused by a malfunction of their primary NTP server. Somehow, the primary NTP server jumping its clock caused all of the clients to jump their clocks, despite your knowledige of how NTP operates. The truth is that implementations of NTP can and do jump the clock, depending on how they are implemented and how large the time difference is. A well-mannered implementation of NTP operates exactly as you say. Not all implementations of NTP are well-mannered. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35746] - session manager should be immune to system clock time changes (solution provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35746. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35746 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 13:44 --- Just to clarify, I proposed 2 ways of avoiding unexpected session expiration. a) on the looping/sleeping thread, detect time shifts and pass it along the stackframes to whichever class wants to know. This is when the looping code know to few about the task to perform, for example if the looping thread doesn't know the job is to assert/expire sessions, but it can pass its knowledge of time and time shifts. That's the piece of code. b) the looping/sleeping thread knows it has to age sessions. Valves or filters (whatever on service()) simply resets the age to 0. Note that if the duration of a sleep/wait could be affected by a system time change, rolling back time 1 hour could lock up a thread for 1 more hour. The old way of expiring session would be just as affected because which ever thread checks for session expiration, it also calls wait/sleep. There is no other jvm primitive to perform such pause. Therefore, the implementation would be just as flawed in the worst case, and fairly expiring session in the best case. - - - As for wait()/sleep() JLS specs (JVM spec doesn't mention it): http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8.1 If this is a timed wait, an internal action removing t from m's wait set that occurs after at least millisecs milliseconds plus nanosecs nanoseconds elapse since the beginning of this wait action. http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.9 Thread.sleep causes the currently executing thread to sleep (temporarily cease execution) for the specified duration, subject to the precision and accuracy of system timers and schedulers. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451831 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core: ApplicationDispatcher.java ApplicationFilterChain.java LocalStrings.properties
Author: markt
Date: Sun Oct 1 15:43:11 2006
New Revision: 451831
URL: http://svn.apache.org/viewvc?view=revrev=451831
Log:
Fix bug 34956. Ensure requestDispatchers are called with original or wrapped
original request/response objects as per SRV.8.2 and SRV.14.2.5.1
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java?view=diffrev=451831r1=451830r2=451831
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Sun Oct 1 15:43:11 2006
@@ -323,6 +323,9 @@
// Set up to handle the specified request and response
setup(request, response, false);
+
+// Check SRV.8.2 / SRV.14.2.5.1 compliance
+checkSameObjects();
// Identify the HTTP-specific request and response objects (if any)
HttpServletRequest hrequest = null;
@@ -506,6 +509,9 @@
// Set up to handle the specified request and response
setup(request, response, true);
+// Check SRV.8.2 / SRV.14.2.5.1 compliance
+checkSameObjects();
+
// Create a wrapped response to use for this request
// ServletResponse wresponse = null;
ServletResponse wresponse = wrapResponse();
@@ -958,4 +964,50 @@
}
+private void checkSameObjects() throws ServletException {
+ServletRequest originalRequest =
+ApplicationFilterChain.getLastServicedRequest();
+ServletResponse originalResponse =
+ApplicationFilterChain.getLastServicedResponse();
+
+boolean same = false;
+ServletRequest dispatchedRequest = appRequest;
+
+while (!same) {
+if (originalRequest.equals(dispatchedRequest)) {
+same = true;
+}
+if (!same dispatchedRequest instanceof ServletRequestWrapper) {
+dispatchedRequest =
+((ServletRequestWrapper) dispatchedRequest).getRequest();
+} else {
+break;
+}
+}
+if (!same) {
+throw new ServletException(sm.getString(
+applicationDispatcher.specViolation.request));
+}
+
+same = false;
+ServletResponse dispatchedResponse = appResponse;
+
+while (!same) {
+if (originalResponse.equals(dispatchedResponse)) {
+same = true;
+}
+
+if (!same dispatchedResponse instanceof ServletResponseWrapper)
{
+dispatchedResponse =
+((ServletResponseWrapper)
dispatchedResponse).getResponse();
+} else {
+break;
+}
+}
+
+if (!same) {
+throw new ServletException(sm.getString(
+applicationDispatcher.specViolation.response));
+}
+}
}
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java?view=diffrev=451831r1=451830r2=451831
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java
Sun Oct 1 15:43:11 2006
@@ -49,7 +49,10 @@
final class ApplicationFilterChain implements FilterChain {
-
+// Used to enforce requirements of SRV.8.2 / SRV.14.2.5.1
+private static ThreadLocal lastServicedRequest = new ThreadLocal();
+private static ThreadLocal lastServicedResponse = new ThreadLocal();
+
// -- Constants
@@ -231,6 +234,8 @@
// We fell off the end of the chain -- call the servlet instance
try {
+lastServicedRequest.set(request);
+lastServicedResponse.set(response);
support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
servlet, request, response);
if ((request instanceof HttpServletRequest)
@@ -274,6 +279,9 @@
DO NOT REPLY [Bug 40528] - missing error message localisations
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40528. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40528 --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 16:21 --- PS Thanks for find the correct messages for these! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451840 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Author: markt Date: Sun Oct 1 16:24:03 2006 New Revision: 451840 URL: http://svn.apache.org/viewvc?view=revrev=451840 Log: Update changelog. Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diffrev=451840r1=451839r2=451840 == --- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original) +++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Sun Oct 1 16:24:03 2006 @@ -24,7 +24,13 @@ fix bug34956/bug: Ensure request and response objects passed to a RequestDispatcher meet the requirements of SRV.8.2 and -SRV.14.2.5.1 (markt) +SRV.14.2.5.1. This is disabled by default. The Java option +code-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true/code +is required to enable this test. (markt) + /fix + fix +bug40528/bug: Add missing message localisations as provided by +Ben Clifford. (markt) /fix fix bug40625/bug: Stop CGIServlet swallowing the root cause of an - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r451831 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core: ApplicationDispatcher.java ApplicationFilterChain.java LocalStrings.properties
Mark Thomas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: markt Date: Sun Oct 1 15:43:11 2006 New Revision: 451831 URL: http://svn.apache.org/viewvc?view=revrev=451831 Log: Fix bug 34956. Ensure requestDispatchers are called with original or wrapped original request/response objects as per SRV.8.2 and SRV.14.2.5.1 I think this fix is very evil enabled by default. I tend to agree on the grounds it is pretty pointless (BTW if you can see a better way of implementing it I'd be happy to come up with an alternative patch). I'd have probably been less strict, and just thrown an ISE from ApplicationDispatcher.wrapRequest/wrapResponse. Mine allows somebody that really wants to program against Tomcat sidestep the check, but doesn't add as much overhead. I don't see why the spec requires this but it does. How about porting the Globals.STRICT_SERVLET_COMPLIANCE feature from the 6.x branch? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r451831 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core: ApplicationDispatcher.java ApplicationFilterChain.java LocalStrings.properties
Bill Barker wrote: I'd have probably been less strict, and just thrown an ISE from ApplicationDispatcher.wrapRequest/wrapResponse. Mine allows somebody that really wants to program against Tomcat sidestep the check, but doesn't add as much overhead. I see how this would be lower overhead since wrapRequest/wrapResponse gets to the 'original' request but they don't get called for non-HTTP cases (an unusual case admittedly but we are in the area of strict compliance with this patch) and I don't get the sidestep bit - can you elaborate? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451846 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Author: markt
Date: Sun Oct 1 17:38:42 2006
New Revision: 451846
URL: http://svn.apache.org/viewvc?view=revrev=451846
Log:
Port fix bug 29727. Changes to env-entry values should take effect on web-app
reload.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java?view=diffrev=451846r1=451845r2=451846
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/deploy/NamingResources.java
Sun Oct 1 17:38:42 2006
@@ -190,10 +190,14 @@
public void addEnvironment(ContextEnvironment environment) {
if (entries.containsKey(environment.getName())) {
-return;
-} else {
-entries.put(environment.getName(), environment.getType());
+if (findEnvironment(environment.getName()).getOverride()) {
+removeEnvironment(environment.getName());
+} else {
+return;
+}
}
+
+entries.put(environment.getName(), environment.getType());
synchronized (envs) {
environment.setNamingResources(this);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451849 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
Author: markt
Date: Sun Oct 1 18:03:00 2006
New Revision: 451849
URL: http://svn.apache.org/viewvc?view=revrev=451849
Log:
Port fix for bug 40528. Add missing messages.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties?view=diffrev=451849r1=451848r2=451849
==
---
tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/jasper/resources/LocalStrings.properties
Sun Oct 1 18:03:00 2006
@@ -108,6 +108,8 @@
jsp.error.beans.nomethod=Cannot find a method to read property ''{0}'' in a
bean of type ''{1}''
jsp.error.beans.nomethod.setproperty=Can''t find a method to write property
''{0}'' of type ''{1}'' in a bean of type ''{2}''
jsp.error.beans.noproperty=Cannot find any information on property ''{0}'' in
a bean of type ''{1}''
+jsp.error.beans.property.conversion=Unable to convert string \{0}\ to class
\{1}\ for attribute \{2}\: {3}
+jsp.error.beans.propertyeditor.notregistered=Property Editor not registered
with the PropertyEditorManager
jsp.error.beans.setproperty.noindexset=Cannot set indexed property
jsp.error.include.tag=Invalid jsp:include tag
jsp.error.include.noflush=jsp:include needs to have \flush=true\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38858] - failed to install tomcat5 service on Tomcat installation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38858. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38858 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 19:06 --- This works for me with the standard settings for TEMP and TMP without having to modify either of them to point to C:\temp. It may be an issue with the NSIS installer. http://sourceforge.net/project/showfiles.php?group_id=22049package_id=15374 has a list of the release notes and there are several issues related to the TEMP directory. It could also be related to the environments on the machines that has the problem. I have checked the Tomcat NSIS script and it does not directly use either the TEMP or TMP environment variables. All evidence points to this being something other than a Tomcat issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r451853 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Author: markt Date: Sun Oct 1 19:09:31 2006 New Revision: 451853 URL: http://svn.apache.org/viewvc?view=revrev=451853 Log: Fix typo. Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diffrev=451853r1=451852r2=451853 == --- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original) +++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Sun Oct 1 19:09:31 2006 @@ -19,7 +19,7 @@ changelog fix bug29727/bug: If env-entry values in web.xml are changed then -ensure new vales are applied when context is reloaded. (markt) +ensure new values are applied when context is reloaded. (markt) /fix fix bug34956/bug: Ensure request and response objects passed to a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37381] - pageContext.forward causes Illegal to clear() when buffer size == 0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37381. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37381 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 20:21 --- This is not a Tomcat bug, this is a whitespace issue in your JSP. %@ page language=java contentType=text/html; charset=ISO-8859-1 pageEncoding=ISO-8859-1 buffer=none % % pageContext.forward(forward.jsp); % will throw an exception. %@ page language=java contentType=text/html; charset=ISO-8859-1 pageEncoding=ISO-8859-1 buffer=none %% pageContext.forward(forward.jsp); % will not throw the exception. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39557] - Include of JSP documents with custom tag libs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39557 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 20:46 --- *** Bug 35252 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35252] - jasper2 produced malformed expanded XML view
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35252. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35252 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 20:46 --- The duplicate has more info on how to reproduce. *** This bug has been marked as a duplicate of 39557 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35552] - JMS destination under Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35552. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35552 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|enhancement --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 20:47 --- Marking this enhancement request as such. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35635] - Tomcat service does not log startup error messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35635. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35635 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 21:20 --- With a default install of the Windows Service Installer for 5.5.20 and the options above specified %CATALINA_HOME%\logs contains jakarta_service_20061002.log and stderr_20061002.log, both of which are zero length. The service related logs are generated by commons-daemon. I have created a JIRA issue for this bug. https://issues.apache.org/jira/browse/DAEMON-88 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30551] - New version of JK Connector(1.2.6) does not seem to be working for POST requests.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30551. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30551 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 21:27 --- *** Bug 35827 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35827] - Problem with POST forms with jk connector/IIS/WindowsXP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35827 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 21:27 --- Please see the related issue, particularly the final comment. It describes exactly the same issue as you are seeing and an upgrade to XP SP2 resolved this issue. Mladen's comments on the related issue are also worth reading to ensure you don't hit the XP client limit. *** This bug has been marked as a duplicate of 30551 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35835] - Submitting changes through admin app corrupts the HTTPS connector definition in server.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35835. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35835 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-10-01 21:33 --- Closing this as fixed since the OP tested it and reported that the issue was fixed in 5.5.11. It is very unlikely that this will be ported to 5.0.x since development has all but stopped on that branch. Comment 5 is not directly related to the original issue. The .exe code and .zip code are identical so the described behaviour is very unexpected. If this is still an issue, please open a new bug report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
