DO NOT REPLY [Bug 40114] Session inadvertently "hijacked" by different after server restart
https://issues.apache.org/bugzilla/show_bug.cgi?id=40114 --- Comment #5 from Denis A. 2010-07-07 03:01:23 EDT --- (In reply to comment #4) > There is a discrepancy between the version the bug was filed under (5.0.26), > and what you declare above; which is it? Sorry about that. It's Tomcat version 5.5.26. I also changed the platform to Windows Server 2003, it was set to Linux initially. I am sure others persons have this problem too. We had it on several servers, all running Windows, not always in a virtual machine. It *seems* to happen randomly a short time after having restarted Tomcat, so another restart often fix it. That's probably why it has been ignored for so long. Original issue and mine are for Tomcat 5.5, so it is maybe related to something which has been fixed in earlier versions. Wild guess: can it be the session ID generator which re-use existing IDs after restart? It can also come from a bug in the application, or MyFaces, or... Any idea? -- 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: [VOTE] Release build 6.0.28
2010/6/30 jean-frederic clere : > Due to bugs (49445 and 49424) and as I was not able to finish the > release process quickly (because of working remotely) and as releases > are cheap we would like to abandon 6.0.27 and propose the vote for 6.0.28 > > The candidates binaries are available here: > http://people.apache.org/~jfclere/tomcat-6/v6.0.28/ > > According to the release process, the 6.0.28 build corresponding to the > tag TOMCAT_6_0_28 is: > [ ] Broken > [ ] Alpha > [ ] Beta > [X] Stable -- Keiichi.Fujino - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49566] New: NullpointerException if /webapps/ROOT is deleted or removed
https://issues.apache.org/bugzilla/show_bug.cgi?id=49566 Summary: NullpointerException if /webapps/ROOT is deleted or removed Product: Tomcat 7 Version: 7.0.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: lff0...@gmail.com I reproduce this issue by Google Chrome, not IE. I created a test servlet (named testServlet) and put it under TOMCAT_HOME/webapps/test/testServlet, and this servlet can be executed as expected. But the following exception is got: An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.connector.Request.getServletContext(Request.java:1541) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:636) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:398) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:249) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:267) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:245) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) >From wiredshark I saw 2 requests. The first request is to my servlet under /test/testServlet which is OK; The second is request to /favicon.ico But I have REMOVED TOMCAT_HOME/webapps/ROOT so this favicon.ico can not be got. But a NPE is not good, I think. After I create a folder named ROOT under webapps and put a favicon.ico under it, this NPE disappears. -- 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: r961313 - in /tomcat/trunk/java/org/apache/el/parser: AstDotSuffix.java AstIdentifier.java
Author: markt
Date: Wed Jul 7 09:10:38 2010
New Revision: 961313
URL: http://svn.apache.org/viewvc?rev=961313&view=rev
Log:
Better error message
Modified:
tomcat/trunk/java/org/apache/el/parser/AstDotSuffix.java
tomcat/trunk/java/org/apache/el/parser/AstIdentifier.java
Modified: tomcat/trunk/java/org/apache/el/parser/AstDotSuffix.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/parser/AstDotSuffix.java?rev=961313&r1=961312&r2=961313&view=diff
==
--- tomcat/trunk/java/org/apache/el/parser/AstDotSuffix.java (original)
+++ tomcat/trunk/java/org/apache/el/parser/AstDotSuffix.java Wed Jul 7
09:10:38 2010
@@ -42,7 +42,8 @@ public final class AstDotSuffix extends
@Override
public void setImage(String image) {
if (!Validation.isIdentifier(image)) {
-throw new ELException("Can't use Java keyword as identifier");
+throw new ELException("[" + image +
+"] is not a valid Java identifier");
}
this.image = image;
}
Modified: tomcat/trunk/java/org/apache/el/parser/AstIdentifier.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/parser/AstIdentifier.java?rev=961313&r1=961312&r2=961313&view=diff
==
--- tomcat/trunk/java/org/apache/el/parser/AstIdentifier.java (original)
+++ tomcat/trunk/java/org/apache/el/parser/AstIdentifier.java Wed Jul 7
09:10:38 2010
@@ -129,7 +129,8 @@ public final class AstIdentifier extends
@Override
public void setImage(String image) {
if (!Validation.isIdentifier(image)) {
-throw new ELException("Can't use Java keyword as identifier");
+throw new ELException("[" + image +
+"] is not a valid Java identifier");
}
this.image = image;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r961317 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Jul 7 09:20:23 2010 New Revision: 961317 URL: http://svn.apache.org/viewvc?rev=961317&view=rev Log: Update proposal, respond to valid parts of veto Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=961317&r1=961316&r2=961317&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jul 7 09:20:23 2010 @@ -158,10 +158,8 @@ PATCHES PROPOSED TO BACKPORT: -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49217 - Prevent use of Java keywords in EL identifiers - http://svn.apache.org/viewvc?rev=960711&view=rev + Ensure EL identifiers conform to the Java Language Specification with an + option to disable this check. + https://issues.apache.org/bugzilla/attachment.cgi?id=25726 +1: markt - -1: kkolinko: r960711 is a testcase, the fix is in r960712 - Regarding r960712 I am -1 because 1) the list of reserved keywords must be shorter, - as I mentioned in Comment #3 for the issue and 2) it might break existing applications, - so I think it must be possible to turn this check off. + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49536] If no webapps deployed, accessing a URL returns 200 OK with no content instead of 404
https://issues.apache.org/bugzilla/show_bug.cgi?id=49536 Mark Thomas changed: What|Removed |Added CC||lff0...@gmail.com --- Comment #4 from Mark Thomas 2010-07-07 05:26:08 EDT --- *** Bug 49566 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 49217] Accepting java keyword in EL
https://issues.apache.org/bugzilla/show_bug.cgi?id=49217 --- Comment #5 from Mark Thomas 2010-07-07 05:19:44 EDT --- Created an attachment (id=25726) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25726) Patch for 6.0.x Back port of changes to 7.0.x with an additional option to disable the check -- 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 49566] NullpointerException if /webapps/ROOT is deleted or removed
https://issues.apache.org/bugzilla/show_bug.cgi?id=49566 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Mark Thomas 2010-07-07 05:26:07 EDT --- *** This bug has been marked as a duplicate of bug 49536 *** -- 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: [VOTE] Release build 6.0.28
On 29.06.2010 17:17, jean-frederic clere wrote: According to the release process, the 6.0.28 build corresponding to the tag TOMCAT_6_0_28 is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable +++ Comments? - MD5 OK - signatures OK - as Konstantin noted: it would be nice if you added your key to the KEYS file you provide in the download directory for the candidates on people.apache.org - Compared contents of gz and zip and svn, looks good. Minor points: - License.rtf was run through fixcrlf on Unix, already fixed in svn - build.properties: it would be nice, if you did the release changes to the file before tagging (and undo after) like Mark does for TC 7 (properties version and version.build). That way checking the identity between the tag and the release source would be easier (less deltas to ignore). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r960864 - /tomcat/tc6.0.x/trunk/STATUS.txt
2010/7/6 Mark Thomas : > On 06/07/2010 12:40, kkoli...@apache.org wrote: >> >> Author: kkolinko >> Date: Tue Jul 6 10:40:16 2010 >> New Revision: 960864 >> >> URL: http://svn.apache.org/viewvc?rev=960864&view=rev >> Log: >> vote >> >> Modified: >> tomcat/tc6.0.x/trunk/STATUS.txt >> >> Modified: tomcat/tc6.0.x/trunk/STATUS.txt >> URL: >> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=960864&r1=960863&r2=960864&view=diff >> >> == >> --- tomcat/tc6.0.x/trunk/STATUS.txt (original) >> +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Jul 6 10:40:16 2010 >> @@ -154,11 +154,14 @@ PATCHES PROPOSED TO BACKPORT: >> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49551 >> Allow default context.xml file to be specified using an absolute path >> http://svn.apache.org/viewvc?rev=960701&view=rev >> - +1: markt >> + +1: markt, kkolinko >> -1: >> >> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49217 >> Prevent use of Java keywords in EL identifiers >> http://svn.apache.org/viewvc?rev=960711&view=rev >> +1: markt >> - -1: >> + -1: kkolinko: r960711 is a testcase, the fix is in r960712 >> + Regarding r960712 I am -1 because 1) the list of reserved keywords >> must be shorter, >> + as I mentioned in Comment #3 for the issue and 2) it might break >> existing applications, > > That analysis is not correct. Java identifier is defined by the Java > language spec, not the EL spec. > I still think that 1) There is no direct example/evidence in the EL spec itself, and I understand that TCK passes without a fix for BZ 49217, because we have released 6.0.26 and 7.0.0 2) There is a separate chapter "Reserved Words" in EL spec, which explicitly lists words that are forbidden as identifiers. It is not mentioned there that Java language keywords are also reserved. It explicitly mentions "instanceof" which is already a Java keyword, as well as mentions "true", "false" and "null". 3) I agree, that it is possible to read the spec in your way, so it makes sense to have such a check, but I think that there must be a way to turn it off. Re: https://issues.apache.org/bugzilla/attachment.cgi?id=25726 The patch is incomplete. The "SKIP_IDENTIFIER_CHECK" property is mentioned in documentation only. It is not used in the code. >> + so I think it must be possible to turn this check off. > > Agreed. I'll propose a back-port with an option to disable once I have > implemented all of the restrictions in the JLS. > > Mark > > 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: r961348 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: rjung Date: Wed Jul 7 11:06:59 2010 New Revision: 961348 URL: http://svn.apache.org/viewvc?rev=961348&view=rev Log: Add trivial proposal (close to C-T-R). Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=961348&r1=961347&r2=961348&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Jul 7 11:06:59 2010 @@ -47,3 +47,26 @@ PATCHES PROPOSED TO BACKPORT: -0: markt - Consensus was for disabled in 5.5.x http://svn.apache.org/viewvc?view=revision&revision=749019 -1: + +* Clean up svn:executable property (svn property cleanup didn't pass the C-T-R discussion) + + a) Remove from Java source files and from docs files + svn propdel svn:executable container/catalina/src/share/org/apache/catalina/valves/ExtendedAccessLogValve.java + svn propdel svn:executable jasper/src/share/org/apache/jasper/xmlparser/ParserUtils.java + svn propdel svn:executable container/webapps/docs/default-servlet.xml + svn propdel svn:executable container/webapps/docs/balancer-howto.xml + svn propdel svn:executable container/webapps/jmxremote/WEB-INF/web.xml + +1: rjung + -1: + + b) Add to .bat and .sh files where missing (most already have the property set) + svn propset svn:executable '*' build/tag.bat + svn propset svn:executable '*' build/tag.sh + svn propset svn:executable '*' build/sign.bat + svn propset svn:executable '*' build/sign.sh + svn propset svn:executable '*' jasper/src/bin/jspc.sh + svn propset svn:executable '*' jasper/src/bin/jspc-using-launcher.sh + svn propset svn:executable '*' jasper/src/bin/jasper.sh + svn propset svn:executable '*' connectors/http11/src/test/test.bat + +1: rjung + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r960864 - /tomcat/tc6.0.x/trunk/STATUS.txt
On 07/07/2010 11:36, Konstantin Kolinko wrote: > 1) There is no direct example/evidence in the EL spec itself, Then I guess you missed the following: Identifier ::= Java language identifier That definition appears in both the 2.1 and 2.2 specification. > and I understand that TCK passes without a fix for BZ 49217, The TCKs are well known not to provide 100% spec coverage. Passing the TCK is necessary but not sufficient to prove complete adherence to the specification. > because we have released 6.0.26 and 7.0.0 > 2) There is a separate chapter "Reserved Words" in EL spec, > which explicitly lists words that are forbidden as identifiers. The current implementation handles those. > It is not mentioned there that Java language keywords are > also reserved. Yes it is. Section 1.19 in the EL 2.2 spec. > 3) I agree, that it is possible to read the spec in your way, > so it makes sense to have such a check, > but I think that there must be a way to turn it off. For 6.0.x, I have no issue with providing an option to disable the check since Tomcat 6.0.x up to this point has been not been fully enforcing the spec. For Tomcat 7, which has only had a single beta release, I see no need to provide the same option. > Re: > https://issues.apache.org/bugzilla/attachment.cgi?id=25726 > The patch is incomplete. The "SKIP_IDENTIFIER_CHECK" property is mentioned > in documentation only. It is not used in the code. Thanks. I was having issues generating the correct patch for 6.0.x and tried to work around them by copying a file from Tomcat 7. I'll update the patch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49217] Accepting java keyword in EL
https://issues.apache.org/bugzilla/show_bug.cgi?id=49217 Mark Thomas changed: What|Removed |Added Attachment #25726|0 |1 is obsolete|| --- Comment #6 from Mark Thomas 2010-07-07 07:33:17 EDT --- Created an attachment (id=25727) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25727) Patch for 6.0.x v2 Updated patch -- 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: r961351 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Jul 7 11:33:33 2010 New Revision: 961351 URL: http://svn.apache.org/viewvc?rev=961351&view=rev Log: Update patch Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=961351&r1=961350&r2=961351&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jul 7 11:33:33 2010 @@ -160,6 +160,6 @@ PATCHES PROPOSED TO BACKPORT: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49217 Ensure EL identifiers conform to the Java Language Specification with an option to disable this check. - https://issues.apache.org/bugzilla/attachment.cgi?id=25726 + https://issues.apache.org/bugzilla/attachment.cgi?id=25727 +1: markt -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Undeploying webapp programatically
Hi, I'm using embedded Tomcat 5.5.23. I undeploy the webapps programmatically using the following code segment: host.removeChild(context); Now, when I send a request to the context which was undeployed, I get an HTTP 503. But I expect to get an HTTP 404 since that resource is not actually available. It seems that the webapp is not completely getting undeployed. What should I do to completely undeploy the webapp so that I get a 404 when a request to the undeployed webapp is made? Thanks Azeez -- Afkham Azeez Senior Software Architect & Product Manager, WSO2 WSAS; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ email: az...@wso2.com cell: +94 77 3320919 blog: http://blog.afkham.org twitter: http://twitter.com/afkham_azeez linked-in: http://lk.linkedin.com/in/afkhamazeez Lean . Enterprise . Middleware - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49567] New: when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 Summary: when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Servlet & JSP API AssignedTo: dev@tomcat.apache.org ReportedBy: pie...@emweb.be Created an attachment (id=25728) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25728) testcase demonstrating the bug when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated. Also, the GET status is: 500 Internal Server Error, however, there is no exception thrown by tomcat. The attached code demonstrates this, by printing "Start async()" an infinite amount of times. -- 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 49528] HttpServletRequest.isAsyncStarted() returns false when a Runnable is started
https://issues.apache.org/bugzilla/show_bug.cgi?id=49528 Pieter Libin changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #11 from Pieter Libin 2010-07-07 09:25:06 EDT --- (In reply to comment #10) > (In reply to comment #9) > > Sorry about that. Fixed in trunk. Will be in 7.0.1 onwards. > > Thanks a lot for the quick response! > I'll retest from the trunk tomorrow morning. this problem appears to be fixed, thanks a lot! However, I ran into another problem, which I reported as new bug (49567). -- 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 49567] when starting a new thread from a startAsync Runnable, an infinite amount of doPosts is generated
https://issues.apache.org/bugzilla/show_bug.cgi?id=49567 Pieter Libin changed: What|Removed |Added CC||pie...@emweb.be -- 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: Undeploying webapp programatically
On 07/07/2010 14:26, Afkham Azeez wrote: > Hi, > I'm using embedded Tomcat 5.5.23. I undeploy the webapps > programmatically using the following code segment: > > host.removeChild(context); > > Now, when I send a request to the context which was undeployed, I get > an HTTP 503. But I expect to get an HTTP 404 since that resource is > not actually available. It seems that the webapp is not completely > getting undeployed. What should I do to completely undeploy the webapp > so that I get a 404 when a request to the undeployed webapp is made? Those are all questions for the users list, not the dev list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49528] HttpServletRequest.isAsyncStarted() returns false when a Runnable is started
https://issues.apache.org/bugzilla/show_bug.cgi?id=49528 Konstantin Kolinko changed: What|Removed |Added Status|VERIFIED|CLOSED -- 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: [VOTE] Release Tomcat 5.5.30 Build
On 01.07.2010 18:11, Jim Jagielski wrote: According to the release process, the 5.5.30 build corresponding to the tag TOMCAT_5_5_30 [1] is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - Signatures OK - Mostly expected differences between tag and src archives, except: - Did you include build/tomcat-5.5.30-build.txt deliberately, so people can see how your build ran? - Directory apache-tomcat-5.5.30/container/modules/groupcom/build is missing It is needed if one build tc 5.5. with "cluster-ha" set in order to build the new Cluster instead of the old one. I'd say it was mostly experimental for 5.5, so not a showstopper and definitely not a regression Thanks for RMing! Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r961383 - in /tomcat/sandbox/tomcat-oacc/trunk: RELEASE-NOTES RUNNING.txt docs/oacc-howto.xml
Author: rjung Date: Wed Jul 7 14:13:29 2010 New Revision: 961383 URL: http://svn.apache.org/viewvc?rev=961383&view=rev Log: Fix docu bug. No need to set Manager class explicitely if the cluster class is correct. Modified: tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt tomcat/sandbox/tomcat-oacc/trunk/docs/oacc-howto.xml Modified: tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES?rev=961383&r1=961382&r2=961383&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES (original) +++ tomcat/sandbox/tomcat-oacc/trunk/RELEASE-NOTES Wed Jul 7 14:13:29 2010 @@ -43,9 +43,8 @@ against the same version of Tomcat, than All cluster configuration options from Tomcat 5.5 should work without any change with OACC. You need to ensure, that you have set the -"managerClassName" explicitely to either -"org.apache.catalina.cluster.session.SimpleTcpReplicationManager" -or "org.apache.catalina.cluster.session.DeltaManager". +"className" in the "Cluster" element explicitely to +"org.apache.catalina.cluster.tcp.SimpleTcpCluster". You don't need to uninstall Tomcat 6 default cluster if you like to use OACC. We don't support mixed use of OACC and Tomcat 6 default cluster Modified: tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt?rev=961383&r1=961382&r2=961383&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt (original) +++ tomcat/sandbox/tomcat-oacc/trunk/RUNNING.txt Wed Jul 7 14:13:29 2010 @@ -69,9 +69,8 @@ subdirectory of your source distribution Tomcat 6 clustering. All cluster configuration options from Tomcat 5.5 should work without any change with OACC. - You need to ensure, that you have set the "managerClassName" explicitely to either - "org.apache.catalina.cluster.session.SimpleTcpReplicationManager" or - "org.apache.catalina.cluster.session.DeltaManager". + You need to ensure, that you have set the "className" in the "Cluster" element + explicitely to "org.apache.catalina.cluster.tcp.SimpleTcpCluster". You don't need to uninstall Tomcat 6 default cluster if you like to use OACC. We don't support mixed use of OACC and Tomcat 6 default cluster Modified: tomcat/sandbox/tomcat-oacc/trunk/docs/oacc-howto.xml URL: http://svn.apache.org/viewvc/tomcat/sandbox/tomcat-oacc/trunk/docs/oacc-howto.xml?rev=961383&r1=961382&r2=961383&view=diff == --- tomcat/sandbox/tomcat-oacc/trunk/docs/oacc-howto.xml (original) +++ tomcat/sandbox/tomcat-oacc/trunk/docs/oacc-howto.xml Wed Jul 7 14:13:29 2010 @@ -1118,7 +1118,6 @@ Between send blocks wait 5 secs to trans when you use the async modes with queues.
Re: Undeploying webapp programatically
I was able to resolve this. It may be helpful for somebody looking for this information. After calling host.removeChild(context), you need to call, ((StandardContext)context).destroy(); Only when destroy is called the context gets completely removed. Thanks Azeez On Wed, Jul 7, 2010 at 7:12 PM, Mark Thomas wrote: > On 07/07/2010 14:26, Afkham Azeez wrote: >> Hi, >> I'm using embedded Tomcat 5.5.23. I undeploy the webapps >> programmatically using the following code segment: >> >> host.removeChild(context); >> >> Now, when I send a request to the context which was undeployed, I get >> an HTTP 503. But I expect to get an HTTP 404 since that resource is >> not actually available. It seems that the webapp is not completely >> getting undeployed. What should I do to completely undeploy the webapp >> so that I get a 404 when a request to the undeployed webapp is made? > > Those are all questions for the users list, not the dev list. > > Mark > > - 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.30 Build
On Jul 7, 2010, at 9:59 AM, Rainer Jung wrote: > On 01.07.2010 18:11, Jim Jagielski wrote: >> According to the release process, the 5.5.30 build corresponding to the >> tag TOMCAT_5_5_30 [1] is: >> >> [ ] Broken >> [ ] Alpha >> [ ] Beta >> [X] Stable > > - MD5 OK > - Signatures OK > - Mostly expected differences between tag and src archives, except: > - Did you include build/tomcat-5.5.30-build.txt deliberately, so people can > see how your build ran? Yes... I thought it would be useful. :) > - Directory apache-tomcat-5.5.30/container/modules/groupcom/build is missing Grrr... >It is needed if one build tc 5.5. with "cluster-ha" set in order to build > the new Cluster instead of the old one. I'd say it was mostly experimental > for 5.5, so not a showstopper and definitely not a regression > I agree... I will wait a few more hours before closing the vote. - 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.30 Build
+1 Stable Test tar.gz with MAC OS X and it works fine. Thanks, Peter Am 01.07.2010 um 18:11 schrieb Jim Jagielski: The builds for Tomcat 5.5.30 are ready for testing and approval. The candidates binaries are available here: http://people.apache.org/~jim/tomcat-5.5/ According to the release process, the 5.5.30 build corresponding to the tag TOMCAT_5_5_30 [1] is: [ ] Broken [ ] Alpha [ ] Beta [x ] Stable +++ 1. http://svn.apache.org/viewvc/tomcat/tc5.5.x/tags/TOMCAT_5_5_30/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Hi! I miss the checkstyle and findbugs quality checks in the project. Marc has contributed a good starting point at https://issues.apache.org/bugzilla/show_bug.cgi?id=49268 Then I can check my personal problem with the tab/space replacement, before checkin code :-) Currently we have in 144 files a tab instead a space replacement issue. Ok, I want to fix it. Later we can add more checkstyles. Who wants to help, me? In the last two years we made a lot of source code cosmetic changes and these help to get a more readable codebase. I think that Marc Guillemot can help us to get more code and test quality to the project. What does the other developers think? Regards Peter Am 05.07.2010 um 11:34 schrieb Mark Thomas: On 05/07/2010 09:27, Marc Guillemot wrote: ma...@apache.org wrote: Author: markt Date: Fri Jul 2 21:13:25 2010 New Revision: 960104 URL: http://svn.apache.org/viewvc?rev=960104&view=rev Log: A few more FindBugs issues > ... why don't you integrate checkstyle (and FindBugs) in the build? The Tomcat code doesn't follow any standards consistently so the number of warnings that would get reported is huge. As far as I am aware the actual problems have been fixed. The remaining issues are cosmetic. There may be some real issues hiding in there somewhere but if there are, they aren't things that users are reporting as problems else there would be a bugzilla entry for it. I don't think (I could be wrong) there is much interest in investing a lot of effort in a bug code clean-up. Gradual improvement seems to be the preferred approach at the moment. It's the only safe way to ensure quality I don't think it is as black and white as that. These tools have their place and I think the Tomcat project has used them appropriately. FindBugs, for example, still reports 1000s of issues but the actual problems were fixed quite some time ago. The cosmetic issues were not. There is a valid argument that fixing the cosmetic issues does more harm than good by making it harder to do diffs between major versions. and to avoid useless style discussions. I don't recall any useless style discussions. I don't think this is an issue we need to solve. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
On 07/07/2010 17:53, Peter Roßbach wrote: > Then I can check my personal problem with the tab/space replacement, > before checkin code :-) > Currently we have in 144 files a tab instead a space replacement issue. There is nothing stopping you running FindBugs, Checkstyle or any other tool locally. I use FindBugs on the Tomact 7 code-base all the time. > Ok, I want to fix it. > > Later we can add more checkstyles. Who wants to help, me? > > In the last two years we made a lot of source code cosmetic changes and > these help to get a more readable codebase. Agreed the code-base is more readable. > I think that Marc Guillemot can help us to get more code and test > quality to the project. My impression is that most of these changes are cosmetic rather than code quality issues. I don't think fixing all the current FindBugs, Checkstyle and Eclipse warnings will result in a significant increase in code quality. It would, however, make it easier to spot when errors do creep in. > What does the other developers think? +0 providing we start with a *very* limited set of checks. There should be very clear agreement amongst a significant majority of the committers to add additional checks. I'd like to see a proposed list of checks before this starts being used on any of the Tomcat code bases. I'd suggest a single check for each of Checkstyle and Findbugs to start. I actually think we'd get more value out of the unused code detector. Going through the 7.0.x codebase and removing unused code is still on my todo list. I suspect there is a reasonable amount we can simply delete. Mark > > Regards > Peter > > Am 05.07.2010 um 11:34 schrieb Mark Thomas: > >> On 05/07/2010 09:27, Marc Guillemot wrote: >>> ma...@apache.org wrote: Author: markt Date: Fri Jul 2 21:13:25 2010 New Revision: 960104 URL: http://svn.apache.org/viewvc?rev=960104&view=rev Log: A few more FindBugs issues >>> > ... >>> >>> why don't you integrate checkstyle (and FindBugs) in the build? >> >> The Tomcat code doesn't follow any standards consistently so the >> number of warnings that would get reported is huge. As far as I am >> aware the actual problems have been fixed. The remaining issues are >> cosmetic. There may be some real issues hiding in there somewhere but >> if there are, they aren't things that users are reporting as problems >> else there would be a bugzilla entry for it. >> >> I don't think (I could be wrong) there is much interest in investing a >> lot of effort in a bug code clean-up. Gradual improvement seems to be >> the preferred approach at the moment. >> >>> It's the only safe way to ensure quality >> >> I don't think it is as black and white as that. These tools have their >> place and I think the Tomcat project has used them appropriately. >> FindBugs, for example, still reports 1000s of issues but the actual >> problems were fixed quite some time ago. The cosmetic issues were not. >> >> There is a valid argument that fixing the cosmetic issues does more >> harm than good by making it harder to do diffs between major versions. >> >>> and to avoid useless style discussions. >> >> I don't recall any useless style discussions. I don't think this is an >> issue we need to solve. >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.28
On 7 July 2010 10:47, Rainer Jung wrote: > On 29.06.2010 17:17, jean-frederic clere wrote: >> >> According to the release process, the 6.0.28 build corresponding to the >> tag TOMCAT_6_0_28 is: >> [ ] Broken >> [ ] Alpha >> [ ] Beta >> [X] Stable >> +++ >> >> Comments? > > - MD5 OK > > - signatures OK > > - as Konstantin noted: it would be nice if you added your key to the KEYS > file you provide in the download directory for the candidates on > people.apache.org > > - Compared contents of gz and zip and svn, looks good. Minor points: > - License.rtf was run through fixcrlf on Unix, already fixed in svn > - build.properties: it would be nice, if you did the release changes to the > file before tagging (and undo after) like Mark does for TC 7 (properties > version and version.build). That way checking the identity between the tag > and the release source would be easier (less deltas to ignore). Or: Create clean workspace from SVN. Make any necessary updates that apply to the tag only. Create the tag from the workspace using svn copy dir https://.../ Trunk is then untainted by unnecessary changes, and the tag commit e-mail shows the changes made. History is also preseved. > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49142] Missing serialVersionUIDs
https://issues.apache.org/bugzilla/show_bug.cgi?id=49142 --- Comment #3 from dbz 2010-07-07 15:56:41 EDT --- Created an attachment (id=25730) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25730) A patch which add a serial version UID to all the classes where it is needed I have added the serial version UID in all classes that are listed by eclipse in the proposed patch serialVersionUID.patch. -- 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: [VOTE] Release build 6.0.28
On 07.07.2010 21:00, sebb wrote: On 7 July 2010 10:47, Rainer Jung wrote: On 29.06.2010 17:17, jean-frederic clere wrote: - build.properties: it would be nice, if you did the release changes to the file before tagging (and undo after) like Mark does for TC 7 (properties version and version.build). That way checking the identity between the tag and the release source would be easier (less deltas to ignore). Or: Create clean workspace from SVN. Make any necessary updates that apply to the tag only. Create the tag from the workspace using svn copy dir https://.../ Trunk is then untainted by unnecessary changes, and the tag commit e-mail shows the changes made. History is also preseved. I personally do not like edits of tags. I think tags should be used as a single cross cut through the code (like in CVS) and uniquely identify one revision, so not be edited. Personal preference though. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r961525 - /tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
Author: markt
Date: Wed Jul 7 22:34:47 2010
New Revision: 961525
URL: http://svn.apache.org/viewvc?rev=961525&view=rev
Log:
Fix some Eclipse warnings
Modified:
tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
Modified: tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java?rev=961525&r1=961524&r2=961525&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java Wed Jul
7 22:34:47 2010
@@ -63,6 +63,7 @@ import org.apache.tomcat.InstanceManager
* @author Tim Fennell
*/
+...@suppresswarnings("deprecation") // Have to support SingleThreadModel
public class JspServletWrapper {
// Logger
@@ -297,10 +298,10 @@ public class JspServletWrapper {
(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
Localizer.getMessage("jsp.error.unavailable"));
return;
-} else {
-// Wait period has expired. Reset.
-available = 0;
}
+
+// Wait period has expired. Reset.
+available = 0;
}
/*
@@ -337,30 +338,26 @@ public class JspServletWrapper {
} catch (ServletException ex) {
if (options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (FileNotFoundException fnfe) {
// File has been removed. Let caller handle this.
throw fnfe;
} catch (IOException ex) {
if (options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (IllegalStateException ex) {
if (options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (Exception ex) {
if (options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw new JasperException(ex);
}
+throw new JasperException(ex);
}
try {
@@ -393,41 +390,37 @@ public class JspServletWrapper {
// a response.sendError() will be ignored by the
// servlet engine.
throw ex;
-} else {
-int unavailableSeconds = ex.getUnavailableSeconds();
-if (unavailableSeconds <= 0) {
-unavailableSeconds = 60;// Arbitrary default
-}
-available = System.currentTimeMillis() +
-(unavailableSeconds * 1000L);
-response.sendError
-(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
- ex.getMessage());
}
+
+int unavailableSeconds = ex.getUnavailableSeconds();
+if (unavailableSeconds <= 0) {
+unavailableSeconds = 60;// Arbitrary default
+}
+available = System.currentTimeMillis() +
+(unavailableSeconds * 1000L);
+response.sendError
+(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
+ ex.getMessage());
} catch (ServletException ex) {
if(options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (IOException ex) {
if(options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (IllegalStateException ex) {
if(options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw ex;
}
+throw ex;
} catch (Exception ex) {
if(options.getDevelopment()) {
throw handleJspException(ex);
-} else {
-throw new JasperException(ex);
}
+throw new JasperException(ex);
}
}
@@ -497,42 +490,40 @@ public class JspServletWrapper {
// parsed JSP to hand, we can't really add anything
return new JasperException(ex);
}
-else {
-int javaLineNumber = jspFrame.getLineNumber();
-JavacErrorDetail detail = ErrorDispatcher.createJavacError(
-jspFrame.getMethodName(),
-
Re: [VOTE] Release build 6.0.28
On 7 July 2010 21:19, Rainer Jung wrote: > On 07.07.2010 21:00, sebb wrote: >> >> On 7 July 2010 10:47, Rainer Jung wrote: >>> >>> On 29.06.2010 17:17, jean-frederic clere wrote: > >>> - build.properties: it would be nice, if you did the release changes to >>> the >>> file before tagging (and undo after) like Mark does for TC 7 (properties >>> version and version.build). That way checking the identity between the >>> tag >>> and the release source would be easier (less deltas to ignore). >> >> Or: >> >> Create clean workspace from SVN. >> >> Make any necessary updates that apply to the tag only. >> >> Create the tag from the workspace using svn copy dir https://.../ >> >> Trunk is then untainted by unnecessary changes, and the tag commit >> e-mail shows the changes made. >> History is also preseved. > > I personally do not like edits of tags. I think tags should be used as a > single cross cut through the code (like in CVS) and uniquely identify one > revision, so not be edited. Personal preference though. My preference too. Tags should be immutable. I see now that my phrase "the tag commit e-mail shows the changes made." could be taken to mean that the tag is editted. However that is not the case. The tag is created from the workspace + changes; the e-mail shows the changes from the initial workspace checkout. So instead of seeing the changes as commits to trunk, followed by a simple SVN copy which creates the tag, the copy and changes appear in the tag creation e-mail itself. OK? > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r961535 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/core/ java/org/apache/jasper/ java/org/apache/jasper/compiler/ java/org/apache/jasper/servlet/ webapps/docs/
Author: markt
Date: Wed Jul 7 23:33:28 2010
New Revision: 961535
URL: http://svn.apache.org/viewvc?rev=961535&view=rev
Log:
Improve logging of unhandled servlet exceptions by including the context name.
For JasperExceptions, the JSP snippet will be logged (if enabled). Previously
this was not logged and only displayed in the error page seen by the user.
Modified:
tomcat/trunk/java/org/apache/catalina/Globals.java
tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/core/StandardWrapperValve.java
tomcat/trunk/java/org/apache/jasper/Constants.java
tomcat/trunk/java/org/apache/jasper/compiler/JavacErrorDetail.java
tomcat/trunk/java/org/apache/jasper/servlet/JspServletWrapper.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/Globals.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Globals.java?rev=961535&r1=961534&r2=961535&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Globals.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Globals.java Wed Jul 7 23:33:28 2010
@@ -177,6 +177,12 @@ public final class Globals {
/**
+ * Platform specific new line sequence.
+ */
+public static final String NEWLINE = System.getProperty("line.separator");
+
+
+/**
* The request attribute under which the request URI of the included
* servlet is stored on an included dispatcher request.
*/
Modified: tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=961535&r1=961534&r2=961535&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties Wed Jul
7 23:33:28 2010
@@ -226,7 +226,8 @@ standardWrapper.notContext=Parent contai
standardWrapper.notFound=Servlet {0} is not available
standardWrapper.notServlet=Class {0} is not a Servlet
standardWrapper.releaseFilters=Release filters exception for servlet {0}
-standardWrapper.serviceException=Servlet.service() for servlet {0} threw
exception
+standardWrapper.serviceException=Servlet.service() for servlet [{0}] in
context with path [{1}] threw exception
+standardWrapper.serviceExceptionRoot=Servlet.service() for servlet [{0}] in
context with path [{1}] threw exception [{2}] with root cause
standardWrapper.statusHeader=HTTP Status {0} - {1}
standardWrapper.statusTitle=Tomcat Error Report
standardWrapper.unavailable=Marking servlet {0} as unavailable
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardWrapperValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardWrapperValve.java?rev=961535&r1=961534&r2=961535&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardWrapperValve.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardWrapperValve.java Wed
Jul 7 23:33:28 2010
@@ -253,14 +253,16 @@ final class StandardWrapperValve
exception(request, response, e);
} catch (IOException e) {
request.removeAttribute(Globals.JSP_FILE_ATTR);
-
container.getLogger().error(sm.getString("standardWrapper.serviceException",
- wrapper.getName()), e);
+container.getLogger().error(sm.getString(
+"standardWrapper.serviceException", wrapper.getName(),
+context.getName()), e);
throwable = e;
exception(request, response, e);
} catch (UnavailableException e) {
request.removeAttribute(Globals.JSP_FILE_ATTR);
-
container.getLogger().error(sm.getString("standardWrapper.serviceException",
- wrapper.getName()), e);
+container.getLogger().error(sm.getString(
+"standardWrapper.serviceException", wrapper.getName(),
+context.getName()), e);
//throwable = e;
//exception(request, response, e);
wrapper.unavailable(e);
@@ -281,15 +283,18 @@ final class StandardWrapperValve
request.removeAttribute(Globals.JSP_FILE_ATTR);
Throwable rootCause = StandardWrapper.getRootCause(e);
if (!(rootCause instanceof ClientAbortException)) {
-
container.getLogger().error(sm.getString("standardWrapper.serviceException",
- wrapper.getName()), rootCause);
+container.getLogger().error(sm.getString(
+"standardWrapper.serviceExceptionRo
svn commit: r961541 - in /tomcat/trunk: java/org/apache/catalina/session/LocalStrings.properties java/org/apache/catalina/session/StandardSession.java webapps/docs/changelog.xml
Author: markt
Date: Thu Jul 8 00:05:38 2010
New Revision: 961541
URL: http://svn.apache.org/viewvc?rev=961541&view=rev
Log:
Include session ID in error message logged when trying to set an attribute on
an invalid session.
Modified:
tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/session/StandardSession.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties?rev=961541&r1=961540&r2=961541&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties Thu
Jul 8 00:05:38 2010
@@ -60,7 +60,7 @@ standardSession.notSerializable=Cannot s
standardSession.removeAttribute.ise=removeAttribute: Session already
invalidated
standardSession.sessionEvent=Session event listener threw exception
standardSession.setAttribute.iae=setAttribute: Non-serializable attribute {0}
-standardSession.setAttribute.ise=setAttribute: Session already invalidated
+standardSession.setAttribute.ise=setAttribute: Session [{0}] has already been
invalidated
standardSession.setAttribute.namenull=setAttribute: name parameter cannot be
null
standardSession.sessionCreated=Created Session id = {0}
persistentManager.loading=Loading {0} persisted sessions
Modified: tomcat/trunk/java/org/apache/catalina/session/StandardSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/StandardSession.java?rev=961541&r1=961540&r2=961541&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/session/StandardSession.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/session/StandardSession.java Thu Jul
8 00:05:38 2010
@@ -1391,8 +1391,8 @@ public class StandardSession
// Validate our current state
if (!isValidInternal())
-throw new IllegalStateException
-(sm.getString("standardSession.setAttribute.ise"));
+throw new IllegalStateException(sm.getString(
+"standardSession.setAttribute.ise", getIdInternal()));
if ((manager != null) && manager.getDistributable() &&
!(value instanceof Serializable))
throw new IllegalArgumentException
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=961541&r1=961540&r2=961541&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Thu Jul 8 00:05:38 2010
@@ -116,6 +116,10 @@
Improve logging of unhandled exceptions in servlets by including the
path of the context where the error occurred. (markt)
+
+Include session ID in error message logged when trying to set an
+attribute on an invalid session. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49488] Infrequent StringIndexOutOfBoundsException in WebappClassLoader
https://issues.apache.org/bugzilla/show_bug.cgi?id=49488 Konstantin Kolinko changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Comment #4 from Konstantin Kolinko 2010-07-07 23:16:49 EDT --- See thread "Webapp reloading issue and intermittent 404 errors" on us...@. http://markmail.org/message/xsrc4ek3bhkhsxi4 http://marc.info/?t=12777315894&w=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
Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
Hi Mark, Mark Thomas wrote: ... There is nothing stopping you running FindBugs, Checkstyle or any other tool locally. I use FindBugs on the Tomact 7 code-base all the time. what about sharing the config and including it into the build? What does the other developers think? +0 providing we start with a *very* limited set of checks. There should be very clear agreement amongst a significant majority of the committers to add additional checks. I'd like to see a proposed list of checks before this starts being used on any of the Tomcat code bases. I'd suggest a single check for each of Checkstyle and Findbugs to start. The checks make sense if they are accepted by the majority of the committers as they should be integral part of the build. This is the reason why I've only proposed one check in patch 49268. According to the negative comments on commits, everybody should agree on following checks FileTabCharacter -> currently 146 failures JavadocType (versionFormat) -> currently 539 failures Following simple steps could be: RedundantImport -> 11 failures UnusedImports -> 53 failures ModifierOrder -> 211 failures RedundantModifier -> 1377 failures (seems that nobody knows the default visibility rule of a public interface) LeftCurly -> 498 failures EqualsHashCode -> 5 failures FinalParameters -> 12763 failures FinalLocalVariable -> 8201 failures (not so much Java developers really know how the power of the final keyword) Additionally it seems that you pay attention at some warnings emitted by your IDE. It would be interesting to express these rules as checkstyle (or whatever) rule that can be checked automatically. Can you list the Eclipse style warnings you try to fix? I agree that coherent code style is only cosmetic in a first time as it doesn't change the resulting byte code. Nevertheless it makes easier to concentrate on the important things: the code content, without being distracted by the form. Therefore it helps to find real problems and make easier to compare files, apply patches, ... Cheers, Marc. -- Blog: http://mguillem.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r960104 - /tomcat/trunk/test/org/apache/catalina/mbeans/TestRegistration.java
I totally argreed with Marc Guillemot. It is time to more invest to the cosmetic things at the tomcat code basis. Peter Am 08.07.2010 um 07:37 schrieb Marc Guillemot: Hi Mark, Mark Thomas wrote: ... There is nothing stopping you running FindBugs, Checkstyle or any other tool locally. I use FindBugs on the Tomact 7 code-base all the time. what about sharing the config and including it into the build? What does the other developers think? +0 providing we start with a *very* limited set of checks. There should be very clear agreement amongst a significant majority of the committers to add additional checks. I'd like to see a proposed list of checks before this starts being used on any of the Tomcat code bases. I'd suggest a single check for each of Checkstyle and Findbugs to start. The checks make sense if they are accepted by the majority of the committers as they should be integral part of the build. This is the reason why I've only proposed one check in patch 49268. According to the negative comments on commits, everybody should agree on following checks FileTabCharacter -> currently 146 failures JavadocType (versionFormat) -> currently 539 failures Following simple steps could be: RedundantImport -> 11 failures UnusedImports -> 53 failures ModifierOrder -> 211 failures RedundantModifier -> 1377 failures (seems that nobody knows the default visibility rule of a public interface) LeftCurly -> 498 failures EqualsHashCode -> 5 failures FinalParameters -> 12763 failures FinalLocalVariable -> 8201 failures (not so much Java developers really know how the power of the final keyword) Additionally it seems that you pay attention at some warnings emitted by your IDE. It would be interesting to express these rules as checkstyle (or whatever) rule that can be checked automatically. Can you list the Eclipse style warnings you try to fix? I agree that coherent code style is only cosmetic in a first time as it doesn't change the resulting byte code. Nevertheless it makes easier to concentrate on the important things: the code content, without being distracted by the form. Therefore it helps to find real problems and make easier to compare files, apply patches, ... Cheers, Marc. -- Blog: http://mguillem.wordpress.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49570] New: The CompressionFilter example should support HTTP proxies to cache gzipped content better by sending Vary: Accept-Encoding header
https://issues.apache.org/bugzilla/show_bug.cgi?id=49570
Summary: The CompressionFilter example should support HTTP
proxies to cache gzipped content better by sending
Vary: Accept-Encoding header
Product: Tomcat 7
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Examples
AssignedTo: dev@tomcat.apache.org
ReportedBy: hathanht...@gmail.com
At the moment the Compression Filter example doesn't send the header "Vary:
Accept-Encoding" with the compressed content (see method writeToGZip(..) in
http://svn.apache.org/repos/asf/tomcat/trunk/webapps/examples/WEB-INF/classes/compressionFilters/CompressionResponseStream.java).
>From many sources like
1. http://httpd.apache.org/docs/2.0/mod/mod_deflate.html#proxies
2. http://developer.yahoo.net/blog/archives/2007/07/high_performanc_3.html
it looks like a "Vary: Accept-Encoding" header should be sent with the
compressed content to make sure proxy servers can serve gzipped content
correctly.
To enhance this example, the method writeToGzip(..) should be updated to send
Vary: Accept-Encoding header like below:
public void writeToGZip(byte b[], int off, int len) throws IOException {
...
response.addHeader("Content-Encoding", "gzip");
response.addHeader("Vary", "Accept-Encoding");
gzipstream = new GZIPOutputStream(output);
...
}
--
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
