What I had was a result generating application (as said before with the command pattern blah blah). Originally this was wrapped by an applet, and the applet was wrapped by a javascript layer. The user interface only communicates through the javascript layer with the applet.
What I did was rewrap the underlying application by a servlet instead of an applet and wrote a new javascript layer polymorph with the old one.
In effect the underlying result generating application is 100% the same for both the client and server version (one goes out on cd, the other is distributed on the web), and the difference between the client and server version is about 3 files in a few hundred.
Up till now this was pretty cool, but since the underlying application that generates the result has no knowlegde of whether it is wrapper by an applet or a servlet, there is no way I can wrap all urls with encodeurl etc or do other servlet or applet specific things.
Too bad, but thanks for the posts anyway !! Like I said, I'll go with the cookie check ;-))
greetz
Hans
At 03:14 PM 7/29/2003 -0500, Mike Curwen wrote:
However, there is an API call to do this for you, so it's not as heinous as it sounds at first. Unless of course, you've already built several hundred pages/servlets, none of which use the encoding methods.
So URL re-writing is supported only if you do something like:
HttpServletResponse.encodeURL("/foo.jsp") or HttpServletResponse.encodeRedirectURL("/foo.jsp")
> -----Original Message----- > From: Hans Wichman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 3:06 PM > To: Tomcat Users List > Subject: RE: sessionids through url rewriting > > > I was afraid you were going to say that ;-(. Guess I will built in a > cookiecheck then... > At 01:29 PM 7/29/2003 -0600, you wrote: > > >Since you are passing your session id through URL, the url > string must > >contain the jsessionid parameter, i.e., you have to encode it. > > > > > >-----Original Message----- > >From: Hans Wichman [mailto:[EMAIL PROTECTED] > >Sent: July 29, 2003 11:51 AM > >To: [EMAIL PROTECTED] > >Subject: sessionids through url rewriting > > > > > >Hi, > >I've read in the servlets specs that tomcat must support session > >management through url rewriting, but nothing happens when I disable > >the cookies (testing in netscape 7, since ie 6 sp1 can't disable the > >cookies). > > > >I have one servlet, let's call it /myServlet, which implements a > >command like pattern wrapping a result generating application, for > >example I call the servlet with > >1) > >localhost:8080/myServlet?command0=load&argument0=&command1=in > it&argumen > >t=1&queue > >length=2 > > > >The servlet parses the command and arguments into command > objects and > >passes them onto an instance of an application which is > stored in each > >users session (each user has his own instance of the > application), the > >application processes the request using templates > blablahblah and the > >servlet gets all the generated content using getResult() dumping it > >into the output stream of the servlet. > > > >Where in this process should the automatic url rewriting occur? I > >haven't got a clue.... Does my own request (see 1) overwrite any > >jsessionid that should automatically be added ? Is url > rewriting only > >supported directly from hyperlinks in a jsp page? > > > >Hope anyone can help, I'm using apache tomcat/4.1.24 (and not 4.1.23 > >;-)) > > > >Hans > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
