I can say with 100% certainty that a servlet invoked with XMLHttpRequest **DOES** have the same access to server-side objects as a non-AJAX request. I say this based on two applications in production that do this all day long, one Struts-based, one not. I also say it based on a number of other applications, some using other frameworks, some using plain servlets, all that do this as well, with no problems.
Now, the two production apps, which are very much AJAX-based, not just using it here and there, are running on Websphere, so that leaves the possibility that there's something going on with Tomcat. However, I generally develop under Tomcat, including most of those other apps I mentioned, and never observed this problem. This isn't to say what your seeing isn't truly an issue, I have no doubt it is... but, the only difference I can conceive of, based on all this experience, between an AJAX request and a normal POST/GET, is the session cookie not being passed in with the AJAX request. I could believe that might happen, and I could also believe it may be different from browser to browser (don't misunderstand, I have no knowledge of this being the case, but it wouldn't shock me). As another poster suggested, I would begin by monitoring the requests going across in Firefox with Firebug, and perhaps TamperData... you should be able to see every detail of the request and response with those... compare an AJAX request with a plain form sumission or link click and see if you notice any difference... I'd bet dollars to donuts you'll find some header missing, or something along those lines. But, unless there's some peculiarity to your server setup or environment, I can tell you for sure there's no fundamental difference to the server between the two types of requests, and by extension, to the servlets/filters that execute to service the request. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, May 21, 2007 2:33 pm, Williams, Allen wrote: > I had posted this question to four different Java fora over four days > and gotten zero replies, when it occurred to me how stupid not to ask > the community that wrote Tomcat. I was just going to post this, which > is a summary that describes what I've found so far: > > -- QUOTE -- > In the interest of informing the community, I'm publishing the results > of four days of testing and debugging of XMLHttpRequests and attributes. > This has led me to the conclusion that servlets invoked with an > XMLHttpRequest do not have the same access to server-side objects > (actually, attributes) as those invoked via the normal URL mechanism. I > don't know why, because if I insert a filter, the filter gets executed, > albeit the first time with the wrong session ID. > > I began this odyssey when a filter in place to check if a user's session > had timed out would fail the first time when invoked with an > XMLHttpRequest, but would work each time thereafter. What I discovered > there was that there were two JSESSIONID cookies stored and being sent > in the browser and the jsp and other servlets were requesting the > correct one. The xml request was not, it was requesting the (old? I > don't know) invalid JSESSIONID. One would think, "OK, I'll just read the > cookies in my servlet, check each ID with > request.isRequestedSessionIdValid(), and force the right one". Wrong. > All of the http session APIs that allow one to manipulate the session ID > and force a good one are deprecated, according to Sun's web site, so the > programmer isn't allowed to find & use a good session ID. > > In order to progress while I waited vainly for a reply, I just removed > the filter from the servlet's path so it didn't invoke it. I want the > filter to check, but decided to move on in the meantime. That's when I > discovered that, evidently, the servlet does not get a valid session ID > either. > > I had the following line in my XMLHttpRequest servlet: > > [code] > HttpSession sess= req.getSession(); > [/code] > > This seemed to execute and work fine, until I needed to access > session-scoped attributes I had defined in other pages or servlets. The > were repeatedly null. When I changed the above line to this: > > [code] > HttpSession sess= req.getSession(false); > [/code] > > the reason was apparent: the servlet was generating a brand new session > for me. So, for some reason, XMLHttpRequests don't get the same > treatment that normal servlets get. I'm going to have to go and modify a > lot of code to pass stuff around as query parameters in URLs, which I > really don't want to do for both aesthetic & security reasons, but see > no alternative. Hopefully, there really is someone out there that knows > more about this than I do and can explain to the community & me what's > going on. > -- END QUOTE -- > > 1. So the last paragraph has my main question in it: why can't I access > attributes in a servlet invoked via an XMLHttpRequest? However, I have > a another important question and a couple of ancillary ones as well: > > 2. What is the difference in the servlet invocation between a regular > URL invocation & an XMLHttpInvocation? > > 3. How can I get my filter to work? I. e., get it the correct session > ID? > > 4. WHY are all the session manipulation APIs deprecated, and, at least > according to Sun's web site, not being replaced? It seems unusual to be > removing control from the programmer/software engineer instead of trying > to give him more control over his environment. With those APIs I could > have fixed this (well, kludged it up, anyway). > > If you need me to post any code, I'll be glad to, but it's really pretty > straightforward. In fact, when I started this adventure, the servlet > was empty except for print statements, and the filter has been in place > & working for months. > > Thanks!! > > anw > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
