You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Treitlinger <tt...@gmail.com> on 2010/08/12 15:25:36 UTC
Tomcat 5.5.23 request.getAttribute("foo") returns unexpected NULL
Hello,
I have a number of JSP pages which use the JSTL core library to set a
request attribute like this:
<c:set var="foo" scope="request" >FOO-VALUE</c:set>
The JSPs then forward to a Servlet like this:
<jsp:forward page="/request.go" />
The Servlet later invokes
String s = (String) request.getAttribute("foo")
At this point I would expect s to be "FOO-VALUE". However after
running without any problem for days, request.getAttribute("foo")
suddenly starts returning NULL, causing NullPointerExceptions later
on.
The application was running in Tomcat 5.5.23 (Linux/Slackware) for
approx 10 days until these exceptions started occurring. After they
had started, they were happening for every single HTTP request. After
a Tomcat restart, the exceptions just continued as before, so we had
to failover to a different machine.
Has anyone seen anything like this before?
Regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected NULL
Posted by Thomas Treitlinger <tt...@gmail.com>.
Hello Chris and Konstantin,
thanks for all your suggestions - we finally tracked down the issue,
and it turns out the root cause here was a flawed deployment process.
In order to preserve the application's context.xml file during
software upgrades, our service engineers stop Tomcat, then remove the
$TOMCAT_HOME/webapps/my-app folder and the my-app.war file. Then they
drop in the new war file and restart Tomcat.
What was missing here was to also remove the application's work folder
in $TOMCAT_HOME/work/Catalina/localhost/my-app, which contains all the
generated servlet code for JSPs. When we checked file stamps for the
faulty JSP, the generated files turned out to be much older than
expected.
So in brief... the JSP that was running was the wrong version, and the
'missing' attribute was never actually set by the JSP.
Nothing wrong with Tomcat 5 after all!
Thanks for your help guys,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected NULL
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/8/12 Thomas Treitlinger <tt...@gmail.com>:
> Hello,
>
> I have a number of JSP pages which use the JSTL core library to set a
> request attribute like this:
> <c:set var="foo" scope="request" >FOO-VALUE</c:set>
>
> The JSPs then forward to a Servlet like this:
> <jsp:forward page="/request.go" />
>
> The Servlet later invokes
> String s = (String) request.getAttribute("foo")
>
Maybe somebody calls your page directly? The usual solution to avoid
that is to move the page into WEB-INF directory. You can <jsp:forward
page="/WEB-INF/_jsp/request.go" />, but nobody can call it directly.
Also there is one more possible catch: if 'c:' prefix is not
associated with a taglib, <c:set will be rendered as text, without
invoking the tag library. Maybe the jsp or other file was corrupted
somehow?
> The application was running in Tomcat 5.5.23 (Linux/Slackware)
I wonder if you can upgrade to a later version. I usually mention this page:
http://tomcat.apache.org/security-5.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected
NULL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas,
On 8/13/2010 8:23 AM, Thomas Treitlinger wrote:
> Using your code, I get the same output, and
> unable to print the value using <c:out>, but that's not what I'm
> trying to do.
Right: I was just wondering if there was some other misconfiguration or
misuse or something that was interfering. When simple things don't work,
it's not surprising that complex things don't.
/Before/ the forward, are you able to pull that attribute out of the
request?
> Most of the time this application works as intended, here is some more detail:
>
> * The JSPs are dumb landing pages - only used to track which URL was requested.
> * The foo value is set on the landing JSP, then the request is
> forwarded to a servlet.
> * The servlet gets a lot of work done.
> * The servlet then creates a response. This is formatted as XML or otherwise.
> * To determine the required format, it checks the foo value set by the
> landing JSP.
Why bother with the landing pages at all? If the servlet does
everything, why not simply map the URL directly to the servlet? I'm sure
this isn't something you can just up and change, since your app has been
architected this way, but you could do something like use the end of the
URL path (aka "file extension") to determine the output: .xml gives you
XML, .html gives you HTML, etc.
I just think if would greatly simplify your life. Anyhow...
> It's at this point that the servlet suddenly got NULL back from getAttribute().
> I have checked for any code that could remove the attribute or set it
> to null and there doesn't seem to be any in the application.
What happens if you wrap the request using a filter to record all
accesses and mutations to the request attributes? That would tell you
two things:
1. If some code is removing/replacing the "foo" attribute
2. If the servlet is accessing the request you think it's accessing
#2 would be an interesting situation... it's possible that the JSP
engine is wrapping the request that the servlet sees, or even wrapping
the request that the JSP sees.
At any rate, you'd get a lot of information from that little filter.
> To me this looks like some kind of Tomcat failure:
> * the incoming HttpServletRequest object has somehow 'lost' the
> attribute set earlier
> * it's not our application code that makes the attribute disappear
> * maybe the attribute is never actually set on the HttpServletRequest?
That would be surprising. I'm sure there's an explanation for it. Try
the above wrapper and let's see what we get.
> As I said, this was running for weeks with no issues and no unusual
> load, then suddenly every request showed this failure.
> Even after Tomcat was restarted, the issue continued.
Was there a Tomcat upgrade involved or anything like that?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxlUhIACgkQ9CaO5/Lv0PD52gCghMSuFPYuD/EsKb3Ip0pJ1Khj
7wkAnjvIsAnel1ysEim61HZFCfNK+KmL
=3UK+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected
NULL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas,
On 8/13/2010 8:23 AM, Thomas Treitlinger wrote:
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Something just occurred to me: do you have a servlet "2.5" version
declared in your webapp's web.xml file? If not, I think you'll want to
do that.
Any luck in the meantime?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxsodAACgkQ9CaO5/Lv0PCp5ACgsfUIRSsKKYzGP5kecfcZRh8F
Cu4An0vgi13Y6YcA6jlZ1Llnvbtn2zYj
=ozxm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected NULL
Posted by Thomas Treitlinger <tt...@gmail.com>.
Hi Chris,
thanks for your reply. Using your code, I get the same output, and
unable to print the value using <c:out>, but that's not what I'm
trying to do.
Most of the time this application works as intended, here is some more detail:
* The JSPs are dumb landing pages - only used to track which URL was requested.
* The foo value is set on the landing JSP, then the request is
forwarded to a servlet.
* The servlet gets a lot of work done.
* The servlet then creates a response. This is formatted as XML or otherwise.
* To determine the required format, it checks the foo value set by the
landing JSP.
Here is one of the landing JSPs:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:set var="foo" scope="request" >XML</c:set>
<jsp:forward page="/request.go" />
This invokes a servlet which has the following code in its doGet():
// get foo value from request
String fooValue = (String) request.getAttribute("foo");
//...
It's at this point that the servlet suddenly got NULL back from getAttribute().
I have checked for any code that could remove the attribute or set it
to null and there doesn't seem to be any in the application.
To me this looks like some kind of Tomcat failure:
* the incoming HttpServletRequest object has somehow 'lost' the
attribute set earlier
* it's not our application code that makes the attribute disappear
* maybe the attribute is never actually set on the HttpServletRequest?
As I said, this was running for weeks with no issues and no unusual
load, then suddenly every request showed this failure.
Even after Tomcat was restarted, the issue continued.
At this stage we're just trying to establish what exactly happened.
Regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected
NULL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/12/2010 9:25 AM, Thomas Treitlinger wrote:
> Hello,
>
> I have a number of JSP pages which use the JSTL core library to set a
> request attribute like this:
> <c:set var="foo" scope="request" >FOO-VALUE</c:set>
>
> The JSPs then forward to a Servlet like this:
> <jsp:forward page="/request.go" />
>
> The Servlet later invokes
> String s = (String) request.getAttribute("foo")
>
> At this point I would expect s to be "FOO-VALUE". However after
> running without any problem for days, request.getAttribute("foo")
> suddenly starts returning NULL, causing NullPointerExceptions later
> on.
Weird. I observe the opposite effect:
- ---------------
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:set var="foo" scope="request" >FOO-VALUE</c:set>
<p>
Using JSTL: <c:out value="${foo}" />
</p>
<p>
Direct-to-request using JSTL: <c:out value="${requestScope.foo}" />
</p>
<p>
Using direct request fetch <%= request.getAttribute("foo") %>
</p>
- ------------
The above emits the following for me:
- ---------------
Using JSTL: ${foo}
Direct-to-request using JSTL: ${requestScope.foo}
Using direct request fetch FOO-VALUE
- ---------------
Can you get the JSTL to print your values using <c:out>?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxkQx8ACgkQ9CaO5/Lv0PDmUACgmxXg1ELeXAS3gH4L75YyQ2tP
u6cAn1ctYpbe6cAnfB3pIe7lry90b6Hm
=54lm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org