With Adrian's help, I was able to deploy Orbeon OPS as its own WebApp in
Tomcat, and forward requests from an existing servlet to it. The advantage of this approach is that it isolates the Orbeon JAR files from the existing WebApp's JAR files, and prevents conflicts. Submission doesn't yet work (it gets a JavaScript error), and the URL rewriting causes a big mess that I don't understand. But the approach in general seems to work. Attached are my instructions for how I did it. It's not a general solution, but more an exploratin into what it would take. The parts that I wrote are minimal configuration and string changes, and are released as public domain. I believe that this method of deployment would be of great advantage in Orbeon adoption, and would like to discuss how to move forward with finishing it. Leigh. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws how-to-forward.html (17K) Download Attachment |
Administrator
|
Leigh,
Thanks for all this work! I guess now we should review your document and see how we can integrated this in Orbeon Forms. For now I have entered an RFE: http://forge.objectweb.org/tracker/index.php?func=detail&aid=306641&group_id=168&atid=350207 -Erik Leigh L Klotz, Jr. wrote: > With Adrian's help, I was able to deploy Orbeon OPS as its own WebApp in > Tomcat, and forward requests from an existing servlet to it. > The advantage of this approach is that it isolates the Orbeon JAR files > from the existing WebApp's JAR files, and prevents conflicts. > > Submission doesn't yet work (it gets a JavaScript error), and the URL > rewriting causes a big mess that I don't understand. > But the approach in general seems to work. > > Attached are my instructions for how I did it. It's not a general > solution, but more an exploratin into what it would take. > The parts that I wrote are minimal configuration and string changes, and > are released as public domain. > > I believe that this method of deployment would be of great advantage in > Orbeon adoption, and would like to discuss how to move forward with > finishing it. > > Leigh. Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
In reply to this post by Leigh L. Klotz Jr
Leigh,
As a follow-up slightly related to your post: the URL rewriting doc has been updated recently: http://www.orbeon.com/ops/doc/reference-url-rewriting (I cannot comment yet about why you hit URL rewriting issues.) -Erik Leigh L Klotz, Jr. wrote: > With Adrian's help, I was able to deploy Orbeon OPS as its own WebApp in > Tomcat, and forward requests from an existing servlet to it. > The advantage of this approach is that it isolates the Orbeon JAR files > from the existing WebApp's JAR files, and prevents conflicts. > > Submission doesn't yet work (it gets a JavaScript error), and the URL > rewriting causes a big mess that I don't understand. > But the approach in general seems to work. > > Attached are my instructions for how I did it. It's not a general > solution, but more an exploratin into what it would take. > The parts that I wrote are minimal configuration and string changes, and > are released as public domain. > > I believe that this method of deployment would be of great advantage in > Orbeon adoption, and would like to discuss how to move forward with > finishing it. > > Leigh. Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Thank you Erik -- that confirms my limited understanding. The URL rewriting is made unnecessary by the servlet integration I've done -- all relative URLs are made to work transparently because the XHTML+XForms that gets converted into HTML+JavaScript is served up under what the page thinks is its original URL, and the /op string never appears in the document's URL.
Unfortunately, when I removed the rewriting from the pipeline, the internally generated references to resources such as images and JavaScript used by OPS XForms stopped working. So this will take some care on your part, I'm sure. But I believe the ability to serve up XHTML+XForms completely transparently (preserving the existing application's URLs) is worth it...it's certainly necessary for me. Leigh.
|
Free forum by Nabble | Edit this page |