I'm using an applet as front-end and servlets as back-end, which works just fine except the JVM warm up time.
Today, I tried to use a servlet to redirect to a page I can't connect from an applet due to the security manager. I can successfully connect and write data to the output stream, but the servlet doesn't appear to be executed.
This is the code snippet from the applet:
and this from the servlet:
Neither in the trace nor in the containers log files are any exceptions thrown.
Not sure what the servlet problem is, but this can't work because of the security restrictions - you're trying to have the applets HTTP request redirected to some other host.
But I don't understand the logic in general: if the applet already knows which page it should replace itself with, why doesn't it just call getAppletContext().showDocument to go to that page?
Joined: Dec 26, 2005
Ulf, there are a number of issues. Firstly, my applet used the browser window as its frame. There is nothing else than the applet, that means I don't want to load the new page in the applet window. Secondly, the applet is not signed. There is actually nothing I need from the client machine what the security manager not allows. Doing as you suggest with will cause Firefox 1.5x and IE to block the new window. I hoped by using a servlet to get around this, but I know that I also have to find a way to trigger the client to open the redirected page in a new window.
The redirect command from the Servlet never reaches the browser, does it? I mean, the http protocol is used, all right, but the redirect command gets written to the applet's in stream, which the browser has got nothing to do with except. The browser and the http protocol providing a conduit for the applet to read/write data, but doesnt interpret the data as it would in case of a request sent from it.
One approch would be to have the servlet open another HttpURLConnection and communicate with the redirected resource rather than actually redirecting the entire request.