OpenLaszlo 4.9 DHTML login servlet forwards but never loads page

Question

I am having some problems at the moment using a LoginServlet running OL 4.9, on Tomcat 7.

• I have Tomcat configured to allow c rossContext to be true , and that allows me to work with other app contexts on the same server. Specifically a Login Servlet . My only other app is the OpenLaszlo presentation server LPS(lps-4.9.0) .
• I am using a Tomcat Request Filter that snoops the incoming addresses and looks for a particular cookie of authentication, which then makes its way to the LoginServlet that does a forwarding to the OpenLaszlo page. This was done to KEEP the cookie alive when the Request Filter was awakened at the loading of the OpenLaszlo page.

All of that is working now.

• There are no errors or warnings in the lps.log file or the localhost.<date>.log either, however the page loading goes on forever, and never completes.

Could it be something that I am passing along in the forwarded URL? I am using at least 2 parameters to cause lzr to be set to "dhtml" and then lzt to be set to "html."

I can't even get a simple <canvas> page with a simple button to load. Has anyone seen this, and been able to fix the problem?

Since I first wrote my description I wrote another plea for help to some friends and ex coworkers, and this will help update the details of what I have discovered thus far.

Here's the scenario: I am using Tomcat 7, and have installed the WAR file for OpenLaszlo 4.9. Alongside of this I created a LoginServlet hierarchy and code and web.xml file just under “webapps”; the same level that lps-4.9.0 is installed.

The sequence of events is the following: 1. A login page comes up that takes the username and password, and sends that off to /LoginServlet to process. Note: I have also written and registered a Request Filter for Tomcat that halts traversal beyone /lps-4.9.0 and checks for proper authentication as I retrieve the cookies from requests trying to access those levels. 2. In the LoginServlet, I am creating a MACH COOKIE that I'll send along with the response, so that the Filter will allow me past the /lps-4.9.0 level. To do this I had to do a FORWARD operation to preserve the cookie. a REDIRECT would just drop them. Since you can't give a relative path higher than the Servlet's root, I had to turn on Tomcat's “crossContext” feature that allows me to do that in the same domain. And I have both contexts registered in Tomcat's conf directory in server.xml, I believe. Anyhow it works. I can grab the /lps-4.9.0 context, get a Request Dispatcher, and then use that dispatcher to FORWARD the request/response pair to my OpenLaszlo file(the LZX file).

So it seems to get as far as LOADING the OpenLaszlo page, but when I perused the console messages in Chrome's Developer Tools debugger, it showed that it was actually trying to use the context of the original request(ie /LoginServlet); and of course that doesn't exist. I guess when I passed along the original request/response pair, the request had the FIRST context used, and then tried to derive the relative path to the file off of that.

QUESTION: Can I just copy the stuff from the original request, but change the context, and forward THAT?  Or architecturally should I try something else?

Thanks, C

Answer 1

And the answer is..... You CAN'T DO IT... Period.

BTW. The Openlaszlo website server is DOWN, DEAD, KAPUT, NIX, GONE, NO MORE...

This will be the final project that I personally implement with the tool with no support.

It's very sad to see something that had the right idea about development cycle times, and keeping the client side GUI construction simple, fast, and easy could be something that dies because of lack of interest? Say wha? Can't be because FLASH was in jeopardy.

I'm pretty sure that we, as programmers, aren't so paranoid about losing our jobs that we think we must spend lots of hours CODING an interface to keep it secret.

I'm certainly not paranoid about it. I know there is NET BEANS for swing type GUIS, and I've heard that GWT has adopted something similar now, and so I'll keep looking for that perfect invention and deal with what is left over.

Critical Path must have been purchased by someone else too, and so the site sponsor has no motivation to keep it alive, while it dies a slow death.