aspose file tools*
The moose likes Servlets and the fly likes Bean is null in an XMLHttpRequest (at first) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Bean is null in an XMLHttpRequest (at first)" Watch "Bean is null in an XMLHttpRequest (at first)" New topic
Author

Bean is null in an XMLHttpRequest (at first)

Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
I have a client/server AJAX-type script, and an Java session-scoped attribute on the server called "user". In order to detect a timout and send the user back to the login screen, there is a filter called "CheckUser" which has been working fine for months, checking for either the session or the user bean being null.

Now, I'm sending an XMLHttpRequest to a servlet (which isn't the first of these, although this is a new servlet). The first request that's sent gets a null user bean (accessed in the filter via a HttpSession.getAttribute() in the "CheckUser" filter), which causes the filter to redirect, and the XMLHttpRequest.response contains the HTML text of the login page. After the first access, the user bean is fine, and the only time I've seen this is in this XMLHttpRequest (and the request is built and sent in a library function that's been working fine in other contexts).

Any idea what's happening here? The request is sent in the onload function for the page, which is the soonest I've ever tried to send a request (all other times have been in response to a user-triggered event). Could there be an initialization issue (I'm skeptical here, because the user bean is set at login, and, by the definition of a session-scoped variable, should be there until logout or timeout; they don't come & go between pages, do they)? If you need me to post any code, I'll be glad to, but I'm not sure what's needed. In fact, I wasn't sure whether to post here or in the Javascript forum, but what with it being the failure of the filter & the bean, this is more of a server-side issue (I think).

TIA,
ANW


-------<br />Thanks & regards,<br />anw
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61428
    
  67

Hmmm, this is not something I've ever come across and I do the exact same sort of thing routinely.

Things I'd try as diagnostic steps were it happening to me:

1) try it from different browsers to see if it's the browser screwing with the session cookie
2) investigate if the session itself in the errant request is the same or different than expected
3) check the timing of the requests... is a race condition somehow being created?
...


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
Ha! As usual, you seem to have hit upon something. #3 (I think) was my comment about initialization, but now I've investigated 1 & 2. Here is the print statement in the filter (as it is when now that I added session checking):

So, I'm now printing out the session. When I first click into the area where the problem url is, I get this:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

Then, when I first click the problem url, I get this:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/members/servlet/ForumMgr' 'org.apache.catalina.session.StandardSessionFacade@1cf662f'
May 18 20:45:58: CheckUser: oFilter: Invalid!! validAccess returned 2

The Invalid message is because the user bean is null. Then, every time after that, I get:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/members/servlet/ForumMgr' 'org.apache.catalina.session.StandardSessionFacade@1cf662f'

Note, of course, that the filter seems to be getting called three times, twice with the same session, once with the "new" session, but now the new session doesn't have a null user bean.

Any further ideas?
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
As an afterthought, wouldn't there only be one "session per session", so to speak?

And, sorry about the smileys- don't know how they got in there. That's just a reference to the function: CheckUser:"do"Filter.
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
I'm continuing to experiment, and maybe I'm only getting two CheckUser's after this initial one where the bean is null (I get three there- two with the original session, then one with a "new" session & a null bean). Don't know if I made a mistake the first time, but the three CheckUser's is only on the first time where the last one is a new session with a null bean.
After that, I get two sessions, the original and the "new" one, but no more null beans. And it's always the same two sessions.
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
Oops! One more comment- consistent with my first post after your reply, I did check the browser. This does not happen in IE, so maybe it's some sort of cookie thing? But, still, why am I getting two sessions?
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
Since I posted this, I've done a lot more testing. It does exactly the same thing in IE. I changed the filter to

so that it wouldn't create a new session if one didn't exist, and, sure 'nuff, the session comes back null, but only the first time. After that, it gets the session, no problem. Perhaps the page & JS is loading and executing before the cookie representing the session is sent back to the server???

TIA
anw
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
OK, more testing. I have printed out the JSESSIONID cookies, and there are multiple (two) of these cookies. I'm not sure what the lifecycles of these JSESSIONIDs are, but they seem to change, and the browser (well, the page) seems to be keeping a couple of them around. The XMLHttpRequest seems to have only one.

When I first go to the page, it has two session id's, which, as we shall see, are a good one and a bad (old?) one. The page sends the good one in for validation, no problem. The XMLHttpRequest sends in only one, and it's the bad one the first time. So, when it first lands on the page, it sends these cookies:

and the page, a jsp, requests the following session:

Then, along comes the xmlhttp request, and here is the cookie:

and the result:

The second time around, it is different. Remember, this is still the XmlHttpRequest, not the page. It hasn't been reloaded since the first pass, above. Cookie-wise:

Note that we now have a brand new JSESSION cookie (!?!) which is the one requested by the XMLHttpRequest:


So, how do I get the right JSESSION cookie in the XMLHttpRequest? Or, get the filter to somehow find out the right one? Why would the request be sending the wrong session id?

Does anyone out there now care to venture an opinion?

TIA
Allen Williams
Ranch Hand

Joined: Sep 04, 2006
Posts: 136
OK, I have FOUND the problem, and for the continued edification of the
community will share my results.

It had to do with the context path. Part of the session ID cookie
is a reference to the path that is used. When I went back and associated this
servlet with a valid "used" path but still without the "CheckUser"
involved, updating through my mod_jk.conf, my web.xml for the mappings,
and, of course, the script itself, it picked up the right session id and
the world is good.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bean is null in an XMLHttpRequest (at first)