tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat 5.5.23 request.getAttribute("foo") returns unexpected NULL
Date Fri, 13 Aug 2010 14:09:22 GMT
-----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


Mime
View raw message