Setting up an external resources directory
Rationale
In some cases, you want to keep the files from Orbeon Forms completely separate from those of your application. You want to deploy the Orbeon Forms web archive (war
) and use it without having to make any change to any of the file inside that archive. This approach has several benefits, including:
Upgrading (or downgrading) Orbeon Forms is easier, as you can just re-deploy an version, without having to do any further changes.
Since you are not going to directly change any of the files inside the Orbeon Forms web archive, you can look at it as one module, and don't need to worry at all about any of the files it contains.
How it works
Orbeon Forms uses resource managers to load most of the files that configure or implement your forms. You can use different resource managers, which look for files in different places, say in a sub-directory inside the web archive (e.g. WEB-INF/resources
), or from the class path (e.g. inside jar files), or in a specific directory on disk. Different resources managers can also be chained, so you can configure Orbeon Forms to look for in location A first, and then in location B next. This is configured with context parameters, which you typically set in the WEB-INF/web.xml
.
To be able to override resources that come with Orbeon Forms without changing any of the files inside the web archive:
Create a directory on disk, in which you put the resources you want to override. Let's assume this directory is
/home/myapp/resources
. So if you want to override properties, you create your own/home/myapp/resources/config/properties-local.xml
. To deploy your PE license, place it in/home/myapp/resources/config/license.xml
.You will instruct Orbeon Forms to first try using a resource manager that is file system based, and that looks for resources in the base directory
/home/myapp/resources
. This is done by setting the following two context parameters:First added context parameter:
Name:
oxf.resources.priority.0
Value:
org.orbeon.oxf.resources.FilesystemResourceManagerFactory
Second added context parameter:
Name:
oxf.resources.priority.0.oxf.resources.filesystem.sandbox-directory
Value:
/home/myapp/resources
You typically set context parameters in the web.xml
, but don't want to do so here, as you don't want to change any of the files inside the web archive. So you will be setting those context parameters at the application server level, and the way you do this depends on what application server you use. See the section below that corresponds to your application server.
With Tomcat
In Tomcat's server.xml
, add the two <parameter>
elements to the <context>
you have there for Orbeon Forms (add a <context>
for Orbeon Forms, if you don't have one already):
With WebLogic
This assumes that you are deploying Orbeon Forms in WebLogic as an enterprise archive (ear
), as described in Installation with WebLogic.
Save the XML file below in to an XML file (say
plan.xml
). This is going to be your WebLogic deployment plan. You keep it in a directory if your choice, separate from Orbeon Forms. (If you are already using a deployment for Orbeon Forms, then amend as appropriate.)From the WebLogic Console, under Deployments, click the checkbox next to orbeon-ear, and click on the Update button.
On the next screen, choose Redeploy the application using the following deployment files. The Source path will most likely be pre-populated with the path in which you have your Orbeon Forms enterprise archive (exploded or as an
ear
file). For the Deployment plan path, select the file you created in step 1. Click Finish to redeploy Orbeon Forms taking into account the context parameters set in the deployment plan.
Step 2 and 3 above assume you use the WebLogic Console to deploy Orbeon Forms. If instead you use java weblogic.Deployer
, on the command line, just add the following parameter to the command you normally use to deploy Orbeon Forms: -plan plan.xml
.
With any container
Web app context parameters are typically defined in the WEB-INF/web.xml
, and some containers provide a mechanism for you to override those parameters without having to change the WEB-INF/web.xml
. We've seen earlier how to do this on Tomcat and WebLogic.
If your container does not provide such a mechanism, or updating the WEB-INF/web.xml
isn't a problem for you, you can point your container to an external resource directory by adding the following to your WEB-INF/web.xml
: