Re: getReader() BUG in tomcat 4.1.30 and beyond ?
Bill Barker wrote: I tested your report on TC 5 and the JKCoyote connector, and it works perfectly. But why didn't you test on 4.1.30 ? Are you saying this bug does _not_ exist in the stable, widely used 4.1.30 release ? If not, that would be quite interesting because tomcat is a java program and should theoretically have the same behavior on all platforms. By the way, I found the bug on JDK 1.4.2 on OS X 10.3.2. I am 99.9% sure that you will see the same bug on 4.1.30 even if you run it under windows or solaris. M.Hockings wrote: Though I was using TC 5.0.25 (standalone) and even tried it in IBM WAS 5.1 Test Environment. Works fine everywhere from what I can see. But why didn't you test on 4.1.30 ? After all, the 4.1.x branch is used by thousands of people in _production_. Many of these people may not move to 5.x for years if ever. If this bug _does_ exist in 4.1.30, it would be quite severe, agreed ? Best regards, --j __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getReader() BUG in tomcat 4.1.30 and beyond ?
j.random.programmer wrote: snip M.Hockings wrote: Though I was using TC 5.0.25 (standalone) and even tried it in IBM WAS 5.1 Test Environment. Works fine everywhere from what I can see. But why didn't you test on 4.1.30 ? After all, the 4.1.x branch is used by thousands of people in _production_. Many of these people may not move to 5.x for years if ever. If this bug _does_ exist in 4.1.30, it would be quite severe, agreed ? Best regards, --j Yes _if_ the bug does exist it would be severe. However, please don't confuse me with a developer, I am simply an interested party that uses TC. I use TC5 for my own stuff and WebSphere at work, why would I wish to install the older TC4? My ISP moved from TC4 to TC5 a while ago. Your note indicates 4.1.30 and beyond, so 5.0.25 is a valid test for beyond is it not? Are you maybe running some framework (like Struts) that may be grabbing the stream before your jsp gets control? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getReader() BUG in tomcat 4.1.30 and beyond ?
M.Hockings wrote: I use TC5 for my own stuff and WebSphere at work, why would I wish to install the older TC4? My ISP moved from TC4 to TC5 a while ago. Your note indicates 4.1.30 and beyond, so 5.0.25 is a valid test for beyond is it not? Yup. You're right about that. Although I meant 4.1.30 and anything else upcoming in the 4.1.x series, at least we now have a data point that the problem does not exist in 5.0.25. You did use POST as the action of your form right ? Are you maybe running some framework (like Struts) that may be grabbing the stream before your jsp gets control? Nope. Straight tomcat. No framework of any kind. It gets curiouser and curiouser. Running tomcat 4.1.30 totally standalone (port 8080) also shows a similar prolem. The reader does not throw a InvalidStateException in this mode, however the stream/reader is empty and the POST'ed data cannot be printed out in the jsp. Note, this problem does not happen with servlets in either standalone or apache+mod_jk mode. There is something in the jsp machinery that is doing something very funky with the request's inputstream. Perhaps a jsp optimization gone horribly wrong ? Someone (a core programmer maybe) should really try to fix this because tomcat 4.1.30/jsp is very broken. Best regards, --j __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getReader() BUG in tomcat 4.1.30 and beyond ?
I have just run a simple test using the latest 4.1.x branch from CVS and I do not see this bug - the data is displayed as expected. This was with tomcat standalone running on port 8080. There are two explanations for this: 1. There is a bug in 4.1.30 that has been fixed in CVS 2. There is something in your setup (maybe a filter?) that is messing with the input stream Either way, the current TC4 (and TC5 from previous posts) code bases are both OK. Mark -Original Message- From: j.random.programmer [mailto:[EMAIL PROTECTED] Sent: Sunday, July 25, 2004 8:12 PM To: [EMAIL PROTECTED] Subject: Re: getReader() BUG in tomcat 4.1.30 and beyond ? M.Hockings wrote: I use TC5 for my own stuff and WebSphere at work, why would I wish to install the older TC4? My ISP moved from TC4 to TC5 a while ago. Your note indicates 4.1.30 and beyond, so 5.0.25 is a valid test for beyond is it not? Yup. You're right about that. Although I meant 4.1.30 and anything else upcoming in the 4.1.x series, at least we now have a data point that the problem does not exist in 5.0.25. You did use POST as the action of your form right ? Are you maybe running some framework (like Struts) that may be grabbing the stream before your jsp gets control? Nope. Straight tomcat. No framework of any kind. It gets curiouser and curiouser. Running tomcat 4.1.30 totally standalone (port 8080) also shows a similar prolem. The reader does not throw a InvalidStateException in this mode, however the stream/reader is empty and the POST'ed data cannot be printed out in the jsp. Note, this problem does not happen with servlets in either standalone or apache+mod_jk mode. There is something in the jsp machinery that is doing something very funky with the request's inputstream. Perhaps a jsp optimization gone horribly wrong ? Someone (a core programmer maybe) should really try to fix this because tomcat 4.1.30/jsp is very broken. Best regards, --j __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getReader() BUG in tomcat 4.1.30 and beyond ?
j.random.programmer wrote: M.Hockings wrote: I use TC5 for my own stuff and WebSphere at work, why would I wish to install the older TC4? My ISP moved from TC4 to TC5 a while ago. Your note indicates 4.1.30 and beyond, so 5.0.25 is a valid test for beyond is it not? Yup. You're right about that. Although I meant 4.1.30 and anything else upcoming in the 4.1.x series, at least we now have a data point that the problem does not exist in 5.0.25. You did use POST as the action of your form right ? Are you maybe running some framework (like Struts) that may be grabbing the stream before your jsp gets control? Nope. Straight tomcat. No framework of any kind. It gets curiouser and curiouser. Running tomcat 4.1.30 totally standalone (port 8080) also shows a similar prolem. The reader does not throw a InvalidStateException in this mode, however the stream/reader is empty and the POST'ed data cannot be printed out in the jsp. Note, this problem does not happen with servlets in either standalone or apache+mod_jk mode. There is something in the jsp machinery that is doing something very funky with the request's inputstream. Perhaps a jsp optimization gone horribly wrong ? Someone (a core programmer maybe) should really try to fix this because tomcat 4.1.30/jsp is very broken. Best regards, --j OK, just because I had nothing better to do this afternoon I downloaded the TC 4.1.30 zip and unpacked it on my laptop (Win2K) and fired it up with j2sdk1.4.2_03... Seems to work just fine to me Maybe your woes stem from some subtlety to do with your platform or Java runtime version? Y'know Java, write once, test everywhere :-) Now, FWIW, I can make it fail with a org.apache.jasper.JasperException: getReader() has already been called for this request If I get and exhaust the reader, close it, then try and get the input stream (or reader) a second time... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getReader() BUG in tomcat 4.1.30 and beyond ?
Yoav Shapira wrote thusly: I saw your message on tomcat-user. Several other Tomcat developers also follow that list. I personally looking at the stack trace chose to discard your message for a few reasons: You reply is retarded; more signifantly you are not and have never been a core developer ON THE JSP CODE. What you choose to do is irrelevant. The bug is very real. That my twice posted message (on both dev and user) got no response from core developers is frightening. - The AJP connector in the stack trace indicates Apache in front of Tomcat, making Apache and the AJP connector possible culprits. Unless you reproduce this with Tomcat standalone, I'm not convinced. A simple servlet using the same setup does not display the bug. I can getInputStream() OR getReader() from a servlet's doPost method and print out the entire POST'ed body. The bug only happens for JSP's in tomcat 4.1.30 and beyond. - The fact it's 4.1.30, which is a mature branch that's been in the market for a while, and if what you're reporting is really true we would have heard about it via bug reports a long time ago. 'tis better to remain silent and appear a fool than to speak and remove all doubt ... (and your above statement removes all doubt). - Also being on a 4.x release, I'm not as interested, because only 5.x is being actively developed. If you reported this error on 5.0.27 standalone tomcat I suspect you would have gotten replies on the tomcat- user list from me and others. Don't matter if you are interested or not. The bug is real and needs to be fixed by the core developers for the hundreds of thousands of people who are using the stable 4.1.x branch today. And if the core developers are so cock-sure that this is not a bug, then why don't they at least say that they could NOT replicate this ? After all, the sample jsp that shows the bug is only a few lines long and extremely simple to test. Again, I don't know what is more troubling: the severity of this bug, your post, or the total lack of response from the core jsp developers (one way or another) Best regards, --j __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getReader() BUG in tomcat 4.1.30 and beyond ?
- Original Message - From: j.random.programmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, July 24, 2004 12:31 PM Subject: RE: getReader() BUG in tomcat 4.1.30 and beyond ? Yoav Shapira wrote thusly: I saw your message on tomcat-user. Several other Tomcat developers also follow that list. I personally looking at the stack trace chose to discard your message for a few reasons: You reply is retarded; more signifantly you are not and have never been a core developer ON THE JSP CODE. What you choose to do is irrelevant. The bug is very real. That my twice posted message (on both dev and user) got no response from core developers is frightening. Ok, a response from a core (connector) developer: I tested your report on TC 5 and the JKCoyote connector, and it works perfectly. Since what I choose to do is also irrelevant (and I wouldn't have it any other way :), I'm choosing not to look into it further. However, if you see this problem on 3.3.2, I'd be more than happy to look at it again ;-). - The AJP connector in the stack trace indicates Apache in front of Tomcat, making Apache and the AJP connector possible culprits. Unless you reproduce this with Tomcat standalone, I'm not convinced. A simple servlet using the same setup does not display the bug. I can getInputStream() OR getReader() from a servlet's doPost method and print out the entire POST'ed body. The bug only happens for JSP's in tomcat 4.1.30 and beyond. - The fact it's 4.1.30, which is a mature branch that's been in the market for a while, and if what you're reporting is really true we would have heard about it via bug reports a long time ago. 'tis better to remain silent and appear a fool than to speak and remove all doubt ... (and your above statement removes all doubt). - Also being on a 4.x release, I'm not as interested, because only 5.x is being actively developed. If you reported this error on 5.0.27 standalone tomcat I suspect you would have gotten replies on the tomcat- user list from me and others. Don't matter if you are interested or not. The bug is real and needs to be fixed by the core developers for the hundreds of thousands of people who are using the stable 4.1.x branch today. Patches are alway welcome ;-). And if the core developers are so cock-sure that this is not a bug, then why don't they at least say that they could NOT replicate this ? After all, the sample jsp that shows the bug is only a few lines long and extremely simple to test. Again, I don't know what is more troubling: the severity of this bug, your post, or the total lack of response from the core jsp developers (one way or another) Best regards, --j __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getReader() BUG in tomcat 4.1.30 and beyond ?
FWIW (I must have too much free time) I tried your hello world example as a recipient of a posted form and it seems to work just fine for me with either request.getReader or request.getInputStream. Though I was using TC 5.0.25 (standalone) and even tried it in IBM WAS 5.1 Test Environment. Works fine everywhere from what I can see. Mike j.random.programmer wrote: Yoav Shapira wrote thusly: I saw your message on tomcat-user. Several other Tomcat developers also follow that list. I personally looking at the stack trace chose to discard your message for a few reasons: You reply is retarded; more signifantly you are not and have never been a core developer ON THE JSP CODE. What you choose to do is irrelevant. The bug is very real. That my twice posted message (on both dev and user) got no response from core developers is frightening. - The AJP connector in the stack trace indicates Apache in front of Tomcat, making Apache and the AJP connector possible culprits. Unless you reproduce this with Tomcat standalone, I'm not convinced. A simple servlet using the same setup does not display the bug. I can getInputStream() OR getReader() from a servlet's doPost method and print out the entire POST'ed body. The bug only happens for JSP's in tomcat 4.1.30 and beyond. - The fact it's 4.1.30, which is a mature branch that's been in the market for a while, and if what you're reporting is really true we would have heard about it via bug reports a long time ago. 'tis better to remain silent and appear a fool than to speak and remove all doubt ... (and your above statement removes all doubt). - Also being on a 4.x release, I'm not as interested, because only 5.x is being actively developed. If you reported this error on 5.0.27 standalone tomcat I suspect you would have gotten replies on the tomcat- user list from me and others. Don't matter if you are interested or not. The bug is real and needs to be fixed by the core developers for the hundreds of thousands of people who are using the stable 4.1.x branch today. And if the core developers are so cock-sure that this is not a bug, then why don't they at least say that they could NOT replicate this ? After all, the sample jsp that shows the bug is only a few lines long and extremely simple to test. Again, I don't know what is more troubling: the severity of this bug, your post, or the total lack of response from the core jsp developers (one way or another) Best regards, --j - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
getReader() BUG in tomcat 4.1.30 and beyond ?
Hi:
I posted this in the tomcat-user but got no replies. I
thought tomcat developers read that list ?
Anyway, here's the problem:
Jsp's unders tomcat 4.1.30 return an empty
request.getInputStream().
If you _don't_ call request.getInputStream() in
your jsp but do call request.getReader(), an
invalid state exception saying that the input
stream has already been opened. Clearly, the
engine is opening the inputstream behind the
scenes and reading all it's input. That's wrong,
non-spec behavior.
For example:
--- hello.jsp -
hello world
h2POST PARAMS/h2
%
java.io.Reader in = request.getReader();
int c = -1;
while ( (c = in.read()) != -1) {
out.print((char)c);
}
%
--
If any form is posted to hello.jsp (i.e, the
action of some form is set to hello.jsp), then
when the form is posted, hello.jsp will crap out.
[if you replaced getReader() in the above code
with getInputStream, the returned input stream
will be empty].
This is ridiculous. Am I missing something ?
Here's the stack trace (NOTE, I am NOT calling
getParamater or similar method, the entire
hello.jsp is shown above). I am NOT NOT NOT
opening the inputstream anywhere.
Once again, here is the ENTIRE .jsp that the form is
posted to.
--- hello.jsp -
hello world
h2POST PARAMS/h2
%
java.io.Reader in = request.getReader();
int c = -1;
while ( (c = in.read()) != -1) {
out.print((char)c);
}
%
--
message Internal Server Error
description The server encountered an internal error
(Internal Server Error) that prevented it from
fulfilling this request.
exception
org.apache.jasper.JasperException: getInputStream()
has already been called for this request
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:457)
at
org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:576)
at java.lang.Thread.run(Thread.java:552)
root cause
java.lang.IllegalStateException: getInputStream() has
already been called for this request
at
org.apache.catalina.connector.RequestBase.getReader(RequestBase.java:911)
at
org.apache.catalina.connector.RequestFacade.getReader(RequestFacade.java:212)
at
org.apache.jsp.hello_jsp._jspService(hello_jsp.java:45)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at
RE: getReader() BUG in tomcat 4.1.30 and beyond ?
Hi,
I saw your message on tomcat-user. Several other Tomcat developers also
follow that list. I personally looking at the stack trace chose to
discard your message for a few reasons:
- The AJP connector in the stack trace indicates Apache in front of
Tomcat, making Apache and the AJP connector possible culprits. Unless
you reproduce this with Tomcat standalone, I'm not convinced.
- The fact it's 4.1.30, which is a mature branch that's been in the
market for a while, and if what you're reporting is really true we would
have heard about it via bug reports a long time ago.
- Also being on a 4.x release, I'm not as interested, because only 5.x
is being actively developed. If you reported this error on 5.0.27
standalone tomcat I suspect you would have gotten replies on the
tomcat-user list from me and others.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: j.random.programmer [mailto:[EMAIL PROTECTED]
Sent: Friday, July 23, 2004 3:58 PM
To: [EMAIL PROTECTED]
Subject: getReader() BUG in tomcat 4.1.30 and beyond ?
Hi:
I posted this in the tomcat-user but got no replies. I
thought tomcat developers read that list ?
Anyway, here's the problem:
Jsp's unders tomcat 4.1.30 return an empty
request.getInputStream().
If you _don't_ call request.getInputStream() in
your jsp but do call request.getReader(), an
invalid state exception saying that the input
stream has already been opened. Clearly, the
engine is opening the inputstream behind the
scenes and reading all it's input. That's wrong,
non-spec behavior.
For example:
--- hello.jsp -
hello world
h2POST PARAMS/h2
%
java.io.Reader in = request.getReader();
int c = -1;
while ( (c = in.read()) != -1) {
out.print((char)c);
}
%
--
If any form is posted to hello.jsp (i.e, the
action of some form is set to hello.jsp), then
when the form is posted, hello.jsp will crap out.
[if you replaced getReader() in the above code
with getInputStream, the returned input stream
will be empty].
This is ridiculous. Am I missing something ?
Here's the stack trace (NOTE, I am NOT calling
getParamater or similar method, the entire
hello.jsp is shown above). I am NOT NOT NOT
opening the inputstream anywhere.
Once again, here is the ENTIRE .jsp that the form is
posted to.
--- hello.jsp -
hello world
h2POST PARAMS/h2
%
java.io.Reader in = request.getReader();
int c = -1;
while ( (c = in.read()) != -1) {
out.print((char)c);
}
%
--
message Internal Server Error
description The server encountered an internal error
(Internal Server Error) that prevented it from
fulfilling this request.
exception
org.apache.jasper.JasperException: getInputStream()
has already been called for this request
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.j
ava:
254)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295
)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic
atio
nFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil
terC
hain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal
ve.j
ava:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invo
keNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal
ve.j
ava:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invo
keNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24
22)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav
a:18
0)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invo
keNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV
alve
.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invo
keNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav
a:16
3)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.
invo
keNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480
