Nic, Craig, Thanks for your help, and Jason Hunter too for his fine book. I have a solution to my problem (a question too), and thought this may be of interest to the others. In a nutshell, the problem is that an applet running in a plugin (within object and embed tags) is apparently totally divorced from the page that it lives in. And the key relationship in a session tracking context is between the web page and the servlet. The ramifications of this is that the cookie passed between the applet and servlet is wrong, and so you will always get a new session, even on return trips to the servelt. Hence no automatic session tracking via cookies. URL rewriting apparently wouldn't work either. My solution was to stream the session id, and use servletcontext to get the session given the id. The problem with my solution is the reliance on deprecated methods and classes. Perhaps everyone knew this but me. But what I just discovered after carefully implementing Hunter's "snoop" example, then transposing it to the applet - servlet situation, is this: The servlet engine (ServletExec) ignores URL rewriting if a cookie is present! Is this standard procedure for servlet engines? And with the wrong cookie present...well, this is why URL rewriting fails. Solution: turn off cookie support for the servlet container, and URL rewriting works just fine for this situation. Fortunately this will work for me because the web server I'm using is dedicated to my application, and I can work around cookies. Obviously if a situation arose where I needed a cookie, I'd be up the creek. Is there a way to force URL rewriting even if a cookie is present? Thanks, Dave Godbey > -----Original Message----- > From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, April 12, 2000 5:39 PM > To: [EMAIL PROTECTED] > Subject: Re: HttpSessionContext - > NeednewmethodHttpServletRequest.getSession(String sessionId) > > "Godbey, David" wrote: > > > Craig, > > Thanks for the info. I tried your suggestions, but its just not working. > I'm > > using Servlet Exec 2.2, and my applet is running in the JRE 1.2 plugin. > > Every round trip begets a NEW session. The URL rewriting as you outlined > > below is also ignored by the servlet. > > I guess I wasn't clear enough ... in order for this to work, you have to > use the > same URL rewriting technique that your servlet engine does. The example I > quoted used the Servlet API 2.2 syntax. You need to double check which > servlet > API version is being supported by ServletExec -- if it's not Servlet API > 2.2 (I > don't know, you'll need to ask them), you need to ask them how they do > their > rewriting (or just do some pages with encoding and see for yourself), then > copy > that style exactly. > > > > > In my research, I've come up with these messages on this topic, > addressing > > both the API (cookie) issue and URL rewriting, both of which are > reported > > below to not work. > > > > http://forum2.java.sun.com/forum?14@@.ee8f661 > > http://forum2.java.sun.com/forum?14@@.ee75c72 > > > > Everything works great if I stick to the <APPLET> tag and native JRE. > But > > <OBJECT> and <EMBED> give no connectivity between the web page and the > > applet (apparently) with respect to the cookie. So every time the applet > > hits the servlet, whoops, getSession gets a brand new id. > > > > I'm by no means an applet guru (native or plugin), but it seems there are > two > aspects to making this whole thing work: > > * How do you tell the applet what the user's session ID is? > > * How does the applet include this session ID on the requests > that it makes itself? > > On the first issue, my suggestion was to pass a parameter to the applet, > as you > generate the page containing it. This parameter would contain the session > ID of > the user's current session, which you acquired with: > > HttpSession session = request.getSession(); > String sessionId = session.getId(); > > According to the HTML 4.0.1 spec at least, you can embed parameters inside > an > OBJECT element: > > <object classid="..." ...> > <param name="sessionid" value="xxxxxxx"> > </object> > > which should (if my understanding is correct) show up as an applet > initialization parameter on IE. The same approach should work with > <applet> for > native-JVM execution. For Netscape's "embed" tag, it looks like you can > just > include the session id as another attribute on the <embed> element itself. > > For the second issue, you need to make sure that you are encoding things > (if > using URL rewriting) or sending a cookie (if using cookies) EXACTLY the > way that > your servlet engine does it for regular pages. If you don't the servlet > is not > going to be able to tell what session you were requesting, so it gives you > a new > one each request. Check the details for your specific engine, for > example, for > what cookie name it uses for the session ID. > > > > > > Are you quite sure about what you've said relative to running applets in > a > > PLUGIN, not the native browser JRE? Is there a way to doctor the header > of > > an output stream to embed the session id? I see that the > HttpServletRequest > > has a method to extract fields from the header. Can I create a cookie in > the > > applet and insert it into the output stream? Say by setRequestProperty > on > > the URLConnection object? > > You can use URLConnection.setRequestProperty() to pass a cookie. The > property > name you're setting is "Cookie", and the value must conform to the cookie > specification (RFC 2109). This sets the header in your outgoing request, > so > that the servlet engine will see the cookie when it reads the request. > > > > > Thanks for your help. > > Dave Godbey > > Craig > > __________________________________________________________________________ > _ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
