-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
