Deploying as web filter
Locked
 
|
I'm looking for advice about deploying the Orbeon XForms processor as a
filter. I've read a couple of mail notes about it, and also read through the web.xml file in the recent nightly to see how it's done inside the ops webapp. It looks to me like if I want to use the Orbeon processor inside another webapp, I'll need to copy files into the other webapp, or deploy them in Tomcat common. Is this correct? Or is there a safe way to invoke this filter from another web-app? The files to copy seem to be - the ops/WEB-INF/lib directory with its 62 jar files - the ops/WEB-INF/lib/private directory with its 2 jar files - some part of the ops/WEB-INF/resources/config directory, perhaps relocated but findable from the web.xml file - The ops/WEB-INF/cli-ops.jar and ops/WEB-INF/commons-cli-1_0.jar files I'm sure this isn't quite right, but even if it is, the 62 jar files confuse me a bit. Surely some of them (junit? jtidy? jms?) aren't required. And some of them are likely to be in conflict with jars required by the existing application, since it already does XML (xalan-2_5_1_orbeon.jar?) Is there a list of required JARs for the XForms processing, as opposed to the JARs required for pipeline processing of various other commands (PDF rendering, XSLT, etc.)? Thank you, Leigh Klotz Xerox -- 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 |
|
|
This is the approach we've taken (copying Orbeon into a an existing web application), although we don't use a servlet filter (instead manually forward to OPSServlet). The *_orbeon.jars are generally safe to put alongside the normal versions because they contain repackaged versions of the libraries (eg orbeon.apache.xerces....) to avoid version conflicts. But there can still be version headaches with the rest of the unpackaged jars. I too would like a list of processor-specific jars - I've removed some by trial & error. Adrian Leigh L Klotz, Jr. wrote: I'm looking for advice about deploying the Orbeon XForms processor as a filter. I've read a couple of mail notes about it, and also read through the web.xml file in the recent nightly to see how it's done inside the ops webapp. It looks to me like if I want to use the Orbeon processor inside another webapp, I'll need to copy files into the other webapp, or deploy them in Tomcat common. Is this correct? Or is there a safe way to invoke this filter from another web-app? The files to copy seem to be - the ops/WEB-INF/lib directory with its 62 jar files - the ops/WEB-INF/lib/private directory with its 2 jar files - some part of the ops/WEB-INF/resources/config directory, perhaps relocated but findable from the web.xml file - The ops/WEB-INF/cli-ops.jar and ops/WEB-INF/commons-cli-1_0.jar files I'm sure this isn't quite right, but even if it is, the 62 jar files confuse me a bit. Surely some of them (junit? jtidy? jms?) aren't required. And some of them are likely to be in conflict with jars required by the existing application, since it already does XML (xalan-2_5_1_orbeon.jar?) Is there a list of required JARs for the XForms processing, as opposed to the JARs required for pipeline processing of various other commands (PDF rendering, XSLT, etc.)? Thank you, Leigh Klotz Xerox -- 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 |
RE: Deploying as web filter
|
|
Thank you Adrian. I was hoping the filter would let
me test an integration without having to understand the API but maybe this way
will be easier.
On the forwarding, how do you accomplish that? Do you
do a rd.forward(request,response)?
Is this before the underlying XHTML+XForms page has been
generated? If so, how does OPSServlet get its input
XHTML+XForms?
If do you somehow wrap the request object before passing it
to the forward?
In general, I don't know if my servlet output contains
XForms until after it's done.
I can then inspect it with XPath and find
out.
Thank you,
Leigh. From: Adrian Baker [mailto:[hidden email]] Sent: Wednesday, January 17, 2007 4:37 PM To: [hidden email] Subject: Re: [ops-users] Deploying as web filter This is the approach we've taken (copying Orbeon into a an existing web application), although we don't use a servlet filter (instead manually forward to OPSServlet). The *_orbeon.jars are generally safe to put alongside the normal versions because they contain repackaged versions of the libraries (eg orbeon.apache.xerces....) to avoid version conflicts. But there can still be version headaches with the rest of the unpackaged jars. I too would like a list of processor-specific jars - I've removed some by trial & error. Adrian Leigh L Klotz, Jr. wrote: I'm looking for advice about deploying the Orbeon XForms processor as a filter. I've read a couple of mail notes about it, and also read through the web.xml file in the recent nightly to see how it's done inside the ops webapp. It looks to me like if I want to use the Orbeon processor inside another webapp, I'll need to copy files into the other webapp, or deploy them in Tomcat common. Is this correct? Or is there a safe way to invoke this filter from another web-app? The files to copy seem to be - the ops/WEB-INF/lib directory with its 62 jar files - the ops/WEB-INF/lib/private directory with its 2 jar files - some part of the ops/WEB-INF/resources/config directory, perhaps relocated but findable from the web.xml file - The ops/WEB-INF/cli-ops.jar and ops/WEB-INF/commons-cli-1_0.jar files I'm sure this isn't quite right, but even if it is, the 62 jar files confuse me a bit. Surely some of them (junit? jtidy? jms?) aren't required. And some of them are likely to be in conflict with jars required by the existing application, since it already does XML (xalan-2_5_1_orbeon.jar?) Is there a list of required JARs for the XForms processing, as opposed to the JARs required for pipeline processing of various other commands (PDF rendering, XSLT, etc.)? Thank you, Leigh Klotz Xerox -- 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 |
|
|
Hi Leigh,
The forward happens after the XHTML+XForms page has been generated. The page gets set as an attribute on the request (using a w3c DOM, but a dom4j DOM or String should also work) which is then forwarded to an instance of OPSServlet: request.setAttribute("xform", <XHTML+XForms DOM>); request.getSession().getServletContext().getRequestDispatcher("<path to OPSServlet>").forward(request, response); The OPSServlet forwarded to is configured to run a simple pipeline which uses the scope generator to extract the request attribute and pass it to the standard epilogue pipeline: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" <p:processor name="oxf:scope-generator"> <p:input name="config"> <config> <key>xform</key> <scope>request</scope> </config> </p:input> <p:output name="data" id="extracted-xform"/> </p:processor> <p:processor name="oxf:pipeline"> <p:input name="config" href="config/epilogue.xpl"/> <p:input name="data" href="#extracted-xform"/> </p:processor> </p:config> But this might not suit your situation because no actual writing to the response is done by this code - it's all done by Orbeon. If you're already writing XHTML+XForms out to the response (which is quite likely the neater approach) then I think you'll need the filter instead. I haven't looked to closely at the epilogue pipeline and it's various sub stages, but my impression was that it's safe to run over a non XForms page. If it's not, you should still be able to introduce an XPath based test in the pipeline to make it's execution conditional.. ? Adrian Klotz, Leigh wrote:
-- 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 |
RE: Deploying as web filter
|
|
I've made some progress on this. I'd like to isolate
the ~41 JAR files in Orbeon from almost certain conflict with the JAR files
required by my application.
Tomcat's way of doing this is to set up different
classloaders for different webapps. So it seems an ideal solution would
have Orbeon in its webapp, my application in its webapp, and then forwarding to
work between th two.
I believe that this would be an idea integration for Orbeon
into existing applications, becuase of the isolation it
affords.
The good news is that this is possible, by giving the
webapp path to getContext(uripath) instead of calling
getContext().
The bad news is that in Tomcat you cannot do this
unless you enable your webapp to forward out.
(For some reason it locks you in your house but lets
anybody in...)
To enable your webapp to be able to forward out, you put
crossContext="true" on your <Context> element in your webapp
config.
The bad news is that the problem is most webapps are
deployed as WAR files and lack the configuration information, because the
docBase and path are determined automagically from the deployment
location. So, there's no Context element to hang the attribute
on.
However, if you bite the bullet and put a Context into the
toplevel tomcat/conf/server.xml file under the appropriate host for your
deployed WAR file that wants to use Orbeon, the approach described above can
work. So if you want your reallyGreatApp webapp to be able to forward
generated content to Orbeon, you stick this in your server.xml
file:
<Context path="/reallyGreatApp"
docBase="C:\Program Files\ReallyGreatApps\v3\dist\tomcat\webapps\reallyGreatApp"
crossContext="true"/>
and then in servlets inside
reallyGreatApp, you gather up the XHTML+XForms content and presumably follow gitn request.setAttribute and pipeline instructions from Adrian's instructions below, but instead of forwarding as described below, you do
this:
String ops ="/ops";
String srv="/myTest/"; RequestDispatcher dispatcher = getServletConfig().getServletContext().getContext(ops).getRequestDispatcher(srv); This is as far as I've
gotten, but I intend to apply Adrian's methodology below. I would
replace srv with "<pathToOPSServlet>" do the
request.setAttribute.
Leigh.
From: Adrian Baker [mailto:[hidden email]] Sent: Thursday, January 18, 2007 12:32 PM To: [hidden email] Subject: Re: [ops-users] Deploying as web filter The forward happens after the XHTML+XForms page has been generated. The page gets set as an attribute on the request (using a w3c DOM, but a dom4j DOM or String should also work) which is then forwarded to an instance of OPSServlet: request.setAttribute("xform", <XHTML+XForms DOM>); request.getSession().getServletContext().getRequestDispatcher("<path to OPSServlet>").forward(request, response); The OPSServlet forwarded to is configured to run a simple pipeline which uses the scope generator to extract the request attribute and pass it to the standard epilogue pipeline: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" <p:processor name="oxf:scope-generator"> <p:input name="config"> <config> <key>xform</key> <scope>request</scope> </config> </p:input> <p:output name="data" id="extracted-xform"/> </p:processor> <p:processor name="oxf:pipeline"> <p:input name="config" href="config/epilogue.xpl"/> <p:input name="data" href="#extracted-xform"/> </p:processor> </p:config> But this might not suit your situation because no actual writing to the response is done by this code - it's all done by Orbeon. If you're already writing XHTML+XForms out to the response (which is quite likely the neater approach) then I think you'll need the filter instead. I haven't looked to closely at the epilogue pipeline and it's various sub stages, but my impression was that it's safe to run over a non XForms page. If it's not, you should still be able to introduce an XPath based test in the pipeline to make it's execution conditional.. ? Adrian Klotz, Leigh wrote:
-- 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 |
RE: Deploying as web filter
|
|
In reply to this post by Adrian Baker
I'm having trouble figuring out how to configure OPSServlet
to run the pipeline below. All the examplesi see in the WAR file nightly
use the <config xmlns="http://www.orbeon.com/oxf/controller">
namespace config, not the pipeline one. I'm not expecting to use
pipelines in my application at all, just XForms, so I don't have any experience
with the pipeline configuration stuff. Is there a place in a tutorial or
example file that shows me how to do this last step?
Thank you, Leigh. From: Adrian Baker [mailto:[hidden email]] Sent: Thursday, January 18, 2007 12:32 PM To: [hidden email] Subject: Re: [ops-users] Deploying as web filter The forward happens after the XHTML+XForms page has been generated. The page gets set as an attribute on the request (using a w3c DOM, but a dom4j DOM or String should also work) which is then forwarded to an instance of OPSServlet: request.setAttribute("xform", <XHTML+XForms DOM>); request.getSession().getServletContext().getRequestDispatcher("<path to OPSServlet>").forward(request, response); The OPSServlet forwarded to is configured to run a simple pipeline which uses the scope generator to extract the request attribute and pass it to the standard epilogue pipeline: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" <p:processor name="oxf:scope-generator"> <p:input name="config"> <config> <key>xform</key> <scope>request</scope> </config> </p:input> <p:output name="data" id="extracted-xform"/> </p:processor> <p:processor name="oxf:pipeline"> <p:input name="config" href="config/epilogue.xpl"/> <p:input name="data" href="#extracted-xform"/> </p:processor> </p:config> But this might not suit your situation because no actual writing to the response is done by this code - it's all done by Orbeon. If you're already writing XHTML+XForms out to the response (which is quite likely the neater approach) then I think you'll need the filter instead. I haven't looked to closely at the epilogue pipeline and it's various sub stages, but my impression was that it's safe to run over a non XForms page. If it's not, you should still be able to introduce an XPath based test in the pipeline to make it's execution conditional.. ? Adrian Klotz, Leigh wrote:
-- 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 |
RE: Deploying as web filter
|
|
In reply to this post by Leigh L. Klotz Jr
I've got the cross-webapp forwarding
working now by putting
<Context path="/xyz" docBase="C:\path\to\webapps\dxyz" crossContext="true"/> into Tomcat's conf/server.xml file. But I'm having trouble figuring out how to follow the directions belowt o configure OPSServlet to run the pipeline below. All the examplesi see in the WAR file nightly use the <config xmlns="http://www.orbeon.com/oxf/controller"> namespace config, not the pipeline one. I'm not expecting to use pipelines in my application at all, just XForms, so I don't have any experience with the pipeline configuration stuff. Is there a place in a tutorial or example file that shows me how to do this last step? Thank you, Leigh.
From: Adrian Baker [mailto:[hidden email]] Sent: Thursday, January 18, 2007 12:32 PM To: [hidden email] Subject: Re: [ops-users] Deploying as web filter The forward happens after the XHTML+XForms page has been generated. The page gets set as an attribute on the request (using a w3c DOM, but a dom4j DOM or String should also work) which is then forwarded to an instance of OPSServlet: request.setAttribute("xform", <XHTML+XForms DOM>); request.getSession().getServletContext().getRequestDispatcher("<path to OPSServlet>").forward(request, response); The OPSServlet forwarded to is configured to run a simple pipeline which uses the scope generator to extract the request attribute and pass it to the standard epilogue pipeline: <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" <p:processor name="oxf:scope-generator"> <p:input name="config"> <config> <key>xform</key> <scope>request</scope> </config> </p:input> <p:output name="data" id="extracted-xform"/> </p:processor> <p:processor name="oxf:pipeline"> <p:input name="config" href="config/epilogue.xpl"/> <p:input name="data" href="#extracted-xform"/> </p:processor> </p:config> But this might not suit your situation because no actual writing to the response is done by this code - it's all done by Orbeon. If you're already writing XHTML+XForms out to the response (which is quite likely the neater approach) then I think you'll need the filter instead. I haven't looked to closely at the epilogue pipeline and it's various sub stages, but my impression was that it's safe to run over a non XForms page. If it's not, you should still be able to introduce an XPath based test in the pipeline to make it's execution conditional.. ? Adrian Klotz, Leigh wrote:
-- 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 |
|
|
Hi Leigh,
I haven't worked pipelines too much, but here's the relevant snippet from my web.xml: <!-- ******************* Orbeon servlets *********************** --> <servlet> <!-- Handles initial display of a form. --> <servlet-name>ops-render-servlet</servlet-name> <servlet-class>org.orbeon.oxf.servlet.OPSServlet</servlet-class> <!-- Set main processor --> <init-param> <param-name>oxf.main-processor.name</param-name> <param-value>{http://www.orbeon.com/oxf/processors}pipeline</param-value> </init-param> <init-param> <param-name>oxf.main-processor.input.config</param-name> <param-value>oxf:/render-form-from-request.xpl</param-value> </init-param> Adrian Leigh L Klotz, Jr. wrote:
-- 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,
See Adrian's response in this thread. In web.xml, you configure OPSServlet to run the oxf:pipeline processor, and you also pass a configuration parameter with the URL of the pipeline to run. This configuration will simply run that pipeline for every request hitting the servlet, instead of running the Page Flow Controller. -Erik Leigh L. Klotz, Jr. wrote: > I'm having trouble figuring out how to configure OPSServlet to run the > pipeline below. All the examplesi see in the WAR file nightly use the > <config xmlns="http://www.orbeon.com/oxf/controller"> namespace config, > not the pipeline one. I'm not expecting to use pipelines in my > application at all, just XForms, so I don't have any experience with the > pipeline configuration stuff. Is there a place in a tutorial or example > file that shows me how to do this last step? > Thank you, > Leigh. > > ------------------------------------------------------------------------ > *From:* Adrian Baker [mailto:[hidden email]] > *Sent:* Thursday, January 18, 2007 12:32 PM > *To:* [hidden email] > *Subject:* Re: [ops-users] Deploying as web filter > > Hi Leigh, > > The forward happens after the XHTML+XForms page has been generated. The > page gets set as an attribute on the request (using a w3c DOM, but a > dom4j DOM or String should also work) which is then forwarded to an > instance of OPSServlet: > > request.setAttribute("xform", <XHTML+XForms DOM>); > > request.getSession().getServletContext().getRequestDispatcher("<path to > OPSServlet>").forward(request, response); > > The OPSServlet forwarded to is configured to run a simple pipeline which > uses the scope generator to extract the request attribute and pass it to > the standard epilogue pipeline: > > <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" > <p:processor name="oxf:scope-generator"> > <p:input name="config"> > <config> > <key>xform</key> > <scope>request</scope> > </config> > </p:input> > <p:output name="data" id="extracted-xform"/> > </p:processor> > <p:processor name="oxf:pipeline"> > <p:input name="config" href="config/epilogue.xpl"/> > <p:input name="data" href="#extracted-xform"/> > </p:processor> > </p:config> > > But this might not suit your situation because no actual writing to the > response is done by this code - it's all done by Orbeon. If you're > already writing XHTML+XForms out to the response (which is quite likely > the neater approach) then I think you'll need the filter instead. > > I haven't looked to closely at the epilogue pipeline and it's various > sub stages, but my impression was that it's safe to run over a non > XForms page. If it's not, you should still be able to introduce an XPath > based test in the pipeline to make it's execution conditional.. ? > > Adrian > > Klotz, Leigh wrote: >> Thank you Adrian. I was hoping the filter would let me test an >> integration without having to understand the API but maybe this way >> will be easier. >> >> On the forwarding, how do you accomplish that? Do you do a >> rd.forward(request,response)? >> Is this before the underlying XHTML+XForms page has been generated? >> If so, how does OPSServlet get its input XHTML+XForms? >> If do you somehow wrap the request object before passing it to the >> forward? >> >> In general, I don't know if my servlet output contains XForms until >> after it's done. >> I can then inspect it with XPath and find out. >> >> Thank you, >> Leigh. >> >> ------------------------------------------------------------------------ >> *From:* Adrian Baker [mailto:[hidden email]] >> *Sent:* Wednesday, January 17, 2007 4:37 PM >> *To:* [hidden email] >> *Subject:* Re: [ops-users] Deploying as web filter >> >> Hi Leigh, >> >> This is the approach we've taken (copying Orbeon into a an existing >> web application), although we don't use a servlet filter (instead >> manually forward to OPSServlet). >> >> The *_orbeon.jars are generally safe to put alongside the normal >> versions because they contain repackaged versions of the libraries (eg >> orbeon.apache.xerces....) to avoid version conflicts. But there can >> still be version headaches with the rest of the unpackaged jars. >> >> I too would like a list of processor-specific jars - I've removed some >> by trial & error. >> >> Adrian >> >> Leigh L Klotz, Jr. wrote: >>> I'm looking for advice about deploying the Orbeon XForms processor as a >>> filter. >>> I've read a couple of mail notes about it, and also read through the >>> web.xml file in the recent nightly to see how it's done inside the ops >>> webapp. >>> >>> It looks to me like if I want to use the Orbeon processor inside another >>> webapp, I'll need to copy files into the other webapp, or deploy them in >>> Tomcat common. Is this correct? Or is there a safe way to invoke this >>> filter from another web-app? >>> >>> The files to copy seem to be >>> - the ops/WEB-INF/lib directory with its 62 jar files >>> - the ops/WEB-INF/lib/private directory with its 2 jar files >>> - some part of the ops/WEB-INF/resources/config directory, >>> perhaps relocated but findable from the web.xml file >>> - The ops/WEB-INF/cli-ops.jar and ops/WEB-INF/commons-cli-1_0.jar files >>> >>> I'm sure this isn't quite right, but even if it is, the 62 jar files >>> confuse me a bit. >>> >>> Surely some of them (junit? jtidy? jms?) aren't required. And some of >>> them are likely to be in conflict with jars required by the existing >>> application, since it already does XML (xalan-2_5_1_orbeon.jar?) >>> >>> Is there a list of required JARs for the XForms processing, as opposed to >>> the JARs required for pipeline processing of various other commands (PDF >>> rendering, XSLT, etc.)? >>> >>> Thank you, >>> Leigh Klotz >>> Xerox 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 |
RE: Deploying as web filter
|
|
In reply to this post by Leigh L. Klotz Jr
Erik,
Thank you. With Adrian's help, I've got it running, not as a filter, but as a dispatcher.forward(request,response) from a servlet in another webapp. This approach, like the filter, allows the preservation of existing webapp urls, but has the advantage that it puts Orbeon (with its many jars) in its own webapp and hence its own classloader. I'll be posting the instructions for doing this, along with a list of problems and workarounds (unfortunately more of the former than the latter). Leigh. -----Original Message----- From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez Sent: Monday, January 29, 2007 2:08 AM To: [hidden email] Subject: Re: [ops-users] Deploying as web filter Leigh, See Adrian's response in this thread. In web.xml, you configure OPSServlet to run the oxf:pipeline processor, and you also pass a configuration parameter with the URL of the pipeline to run. This configuration will simply run that pipeline for every request hitting the servlet, instead of running the Page Flow Controller. -Erik Leigh L. Klotz, Jr. wrote: > I'm having trouble figuring out how to configure OPSServlet to run the > pipeline below. All the examplesi see in the WAR file nightly use the > <config xmlns="http://www.orbeon.com/oxf/controller"> namespace config, > not the pipeline one. I'm not expecting to use pipelines in my > application at all, just XForms, so I don't have any experience with the > pipeline configuration stuff. Is there a place in a tutorial or example > file that shows me how to do this last step? > Thank you, > Leigh. > > ------------------------------------------------------------------------ > *From:* Adrian Baker [mailto:[hidden email]] > *Sent:* Thursday, January 18, 2007 12:32 PM > *To:* [hidden email] > *Subject:* Re: [ops-users] Deploying as web filter > > Hi Leigh, > > The forward happens after the XHTML+XForms page has been generated. The > page gets set as an attribute on the request (using a w3c DOM, but a > dom4j DOM or String should also work) which is then forwarded to an > instance of OPSServlet: > > request.setAttribute("xform", <XHTML+XForms DOM>); > > request.getSession().getServletContext().getRequestDispatcher("<path to > OPSServlet>").forward(request, response); > > The OPSServlet forwarded to is configured to run a simple pipeline which > uses the scope generator to extract the request attribute and pass it to > the standard epilogue pipeline: > > <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" > <p:processor name="oxf:scope-generator"> > <p:input name="config"> > <config> > <key>xform</key> > <scope>request</scope> > </config> > </p:input> > <p:output name="data" id="extracted-xform"/> > </p:processor> > <p:processor name="oxf:pipeline"> > <p:input name="config" href="config/epilogue.xpl"/> > <p:input name="data" href="#extracted-xform"/> > </p:processor> > </p:config> > > But this might not suit your situation because no actual writing to the > response is done by this code - it's all done by Orbeon. If you're > already writing XHTML+XForms out to the response (which is quite likely > the neater approach) then I think you'll need the filter instead. > > I haven't looked to closely at the epilogue pipeline and it's various > sub stages, but my impression was that it's safe to run over a non > XForms page. If it's not, you should still be able to introduce an XPath > based test in the pipeline to make it's execution conditional.. ? > > Adrian > > Klotz, Leigh wrote: >> Thank you Adrian. I was hoping the filter would let me test an >> integration without having to understand the API but maybe this way >> will be easier. >> >> On the forwarding, how do you accomplish that? Do you do a >> rd.forward(request,response)? >> Is this before the underlying XHTML+XForms page has been generated? >> If so, how does OPSServlet get its input XHTML+XForms? >> If do you somehow wrap the request object before passing it to the >> forward? >> >> In general, I don't know if my servlet output contains XForms until >> after it's done. >> I can then inspect it with XPath and find out. >> >> Thank you, >> Leigh. >> >> ------------------------------------------------------------------------ >> *From:* Adrian Baker [mailto:[hidden email]] >> *Sent:* Wednesday, January 17, 2007 4:37 PM >> *To:* [hidden email] >> *Subject:* Re: [ops-users] Deploying as web filter >> >> Hi Leigh, >> >> This is the approach we've taken (copying Orbeon into a an existing >> web application), although we don't use a servlet filter (instead >> manually forward to OPSServlet). >> >> The *_orbeon.jars are generally safe to put alongside the normal >> versions because they contain repackaged versions of the libraries (eg >> orbeon.apache.xerces....) to avoid version conflicts. But there can >> still be version headaches with the rest of the unpackaged jars. >> >> I too would like a list of processor-specific jars - I've removed some >> by trial & error. >> >> Adrian >> >> Leigh L Klotz, Jr. wrote: >>> I'm looking for advice about deploying the Orbeon XForms processor as a >>> filter. >>> I've read a couple of mail notes about it, and also read through the >>> web.xml file in the recent nightly to see how it's done inside the ops >>> webapp. >>> >>> It looks to me like if I want to use the Orbeon processor inside another >>> webapp, I'll need to copy files into the other webapp, or deploy them in >>> Tomcat common. Is this correct? Or is there a safe way to invoke this >>> filter from another web-app? >>> >>> The files to copy seem to be >>> - the ops/WEB-INF/lib directory with its 62 jar files >>> - the ops/WEB-INF/lib/private directory with its 2 jar files >>> - some part of the ops/WEB-INF/resources/config directory, >>> perhaps relocated but findable from the web.xml file >>> - The ops/WEB-INF/cli-ops.jar and ops/WEB-INF/commons-cli-1_0.jar files >>> >>> I'm sure this isn't quite right, but even if it is, the 62 jar files >>> confuse me a bit. >>> >>> Surely some of them (junit? jtidy? jms?) aren't required. And some of >>> them are likely to be in conflict with jars required by the existing >>> application, since it already does XML (xalan-2_5_1_orbeon.jar?) >>> >>> Is there a list of required JARs for the XForms processing, as opposed to >>> the JARs required for pipeline processing of various other commands (PDF >>> rendering, XSLT, etc.)? >>> >>> Thank you, >>> Leigh Klotz >>> Xerox -- 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 |
|
|
Hello Leigh,
Thursday, February 1, 2007, 3:24:36 PM, you wrote: > With Adrian's help, I've got it running, not as a filter, but as a > dispatcher.forward(request,response) from a servlet in another webapp. > This approach, like the filter, allows the preservation of existing webapp > urls, but has the advantage that it puts Orbeon (with its many jars) in > its own webapp and hence its own classloader. > I'll be posting the instructions for doing this, along with a list of > problems and workarounds (unfortunately more of the former than the > latter). It will be very interesting, I am also trying to set Orbeon as a filter for XForm application. I successfully run a few tests but didn't get to the integration part. -- Best regards, Ivan mailto:[hidden email] -- 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 |
«
Return to Orbeon Forms community mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |