DO NOT REPLY [Bug 51106] New: Error page handling serves most general exeptions first
https://issues.apache.org/bugzilla/show_bug.cgi?id=51106 Summary: Error page handling serves most general exeptions first Product: Tomcat 7 Version: 7.0.11 Platform: PC Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: the4ye...@gmail.com Apache Tomcat v7.0.11-x64 Catalina PC/Windows 7 Enterprise x64 java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) How to reproduce the problem? error-page exception-typemy.MyException/exception-type location/exceptions/my_exception.jsp/location /error-page error-page exception-typejava.lang.Exception/exception-type location/exceptions/all.jsp/location /error-page and then throw new ServletException(new MyException(msg)) the code in StandardHostValve first tries to find the error page for the wrapping exception, then for the cause - therefore MyException is never handled in the right place. -- 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: r1095686 - in /tomcat/trunk/java/org/apache/jasper: compiler/DefaultErrorHandler.java resources/LocalStrings.properties
2011/4/21 ma...@apache.org:
Author: markt
Date: Thu Apr 21 12:50:40 2011
New Revision: 1095686
URL: http://svn.apache.org/viewvc?rev=1095686view=rev
Log:
i18n for r1090763
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/DefaultErrorHandler.java
tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
--- tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/jasper/resources/LocalStrings.properties Thu
Apr 21 12:50:40 2011
@@ -336,6 +336,7 @@ jsp.error.needAlternateJavaEncoding=Defa
jsp.error.single.line.number=An error occurred at line: {0} in the jsp file:
{1}
jsp.error.multiple.line.number=\n\nAn error occurred between lines: {0} and
{1} in the jsp file: {2}\n\n
jsp.error.java.line.number=An error occurred at line: {0} in the generated
java file
+jsp.error.location=line: {0}, column {1}
Maybe
jsp.error.location=line: {0,number,0}, column: {1,number,0}
1) missing second ':'
2) numbers by default are formatted with thousands separator, e.g. 1
234. I'd like to avoid the separator.
I do not remember whether ,0 is sufficient to suppress the thousands
separator, or ,###0 will be needed. - needs some testing.
jsp.error.corresponding.servlet=Generated servlet error:\n
jsp.error.empty.body.not.allowed=Empty body not allowed for {0}
jsp.error.jspbody.required=Must use jsp:body to specify tag body for {0} if
jsp:attribute is used.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51108] New: The identifier [new] is not a valid Java identifier
https://issues.apache.org/bugzilla/show_bug.cgi?id=51108
Summary: The identifier [new] is not a valid Java identifier
Product: Tomcat 7
Version: 7.0.11
Platform: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: til...@snafu.de
This JSP code that worked fine with Tomcat 6 is no longer valid in the Tomcat 7
version that comes bundled with Netbeans 7:
${pageContext.session.new}
javax.el.ELException: The identifier [new] is not a valid Java identifier as
required by section 1.19 of the EL specification (Identifier ::= Java language
identifier). This check can be disabled by setting the system property
org.apache.el.parser.SKIP_IDENTIFIER_CHECK to true.
After reading Bug 50147, I've understood what this is about. However, I think
that you're biting yourself - using .new like I did isn't about some
developer who made a poor choice with a function name, it is the EL version of
using a standard library call: %=pageContext.getSession().isNew()% .
I suspect that sooner or later, every JSP user (and possibly also JSF and
Spring users if it happens there too) with Tomcat 7 will have to enable this
SKIP_IDENTIFIER_CHECK property, so setting this property to false by default
isn't really the best idea you ever had.
So my suggestion is to set it to true by default again, maybe for Tomcat 8 :-)
--
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 47371] EL expression parser error when getter methed return an empty string
https://issues.apache.org/bugzilla/show_bug.cgi?id=47371
gbt gilles.bardouil...@atosorigin.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #2 from gbt gilles.bardouil...@atosorigin.com 2011-04-22 10:04:48
EDT ---
Even without string concatenation, you receive the NumberFormat exception with
the following expression :
${4+currentRow['a'].cellValue}
With ${4+currentRow['b'].cellValue}, the result is OK.
Why the empty string test is placed after the String instance test inside the
method org.apache.el.lang.ELArithmetic.coerce ?
--
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 47371] EL expression parser error when getter methed return an empty string
https://issues.apache.org/bugzilla/show_bug.cgi?id=47371 gbt gilles.bardouil...@atosorigin.com changed: What|Removed |Added CC||gilles.bardouillet@atosorig ||in.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51108] The identifier [new] is not a valid Java identifier
https://issues.apache.org/bugzilla/show_bug.cgi?id=51108
Konstantin Kolinko knst.koli...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||DUPLICATE
OS/Version||All
--- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2011-04-22
11:07:39 EDT ---
Just write your code as ${pageContext.session['new']}
The default will not be changed, because of specification compliance.
*** This bug has been marked as a duplicate of bug 50147 ***
--
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 50147] [static] is not a valid Java identifier
https://issues.apache.org/bugzilla/show_bug.cgi?id=50147 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added CC||til...@snafu.de --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com 2011-04-22 11:07:39 EDT --- *** Bug 51108 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 47371] EL expression parser error when getter methed return an empty string
https://issues.apache.org/bugzilla/show_bug.cgi?id=47371 --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com 2011-04-22 11:23:11 EDT --- Confirming in trunk, both the original issue and the one in Comment 2. From expression_language-2_2-mrel-spec.pdf: The '+' operator is defined in chapter 1.7.1. There is the following step there: Otherwise coerce both A and B to Long and apply operator Coercion to Long is covered by chapter 1.18.3. If A is null or , return 0. Throwing a NumberFormatException for the empty string is a 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 47371] EL expression parser error when getter methed return an empty string
https://issues.apache.org/bugzilla/show_bug.cgi?id=47371 --- Comment #4 from gbt gilles.bardouil...@atosorigin.com 2011-04-22 12:30:59 EDT --- Created an attachment (id=26928) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26928) Patch for ELArithmetic -- 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: r1095794 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11Processor.java webapps/docs/changelog.xml
On 21/04/2011 20:25, Filip Hanik - Dev Lists wrote:
On 4/21/2011 1:02 PM, ma...@apache.org wrote:
+int firstReadTimeout;
+if (queueTime= standardTimeout) {
+// Queued for longer than timeout but there
might be
+// data so use shortest possible timeout
+firstReadTimeout = 1;
+} else {
+// Cast is safe since queueTime must be less
than
+// standardTimeout which is an int
+firstReadTimeout = standardTimeout - (int)
queueTime;
+}
+socket.getSocket().setSoTimeout(firstReadTimeout);
+if (!inputBuffer.fill()) {
+throw new
EOFException(sm.getString(iib.eof.error));
}
}
+if (standardTimeout 0) {
+socket.getSocket().setSoTimeout(standardTimeout);
+}
+
inputBuffer.parseRequestLine(false);
not fully understanding the logic here. But if you ever run into a case
where standardTimeout=0 and firstReadTimeout=1, then you'd have 1
millisecond timeout for the parse request line.
Can't happen. Look at the if statement you cut off just above the code
you quoted above.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
