Orbeon Forms
Search…
Properties

Overview

Orbeon Forms is configured via configuration properties. They are usually setup in a file called properties-local.xml and stored in the Orbeon Forms WAR file as:
1
WEB-INF/resources/config/properties-local.xml
Copied!
Orbeon Forms will do a certain number of things out of the box without you having to setup anything in your properties-local.xml. But if you want to change the default behavior (and it is likely you will want to in order to setup access control, database access, configure buttons, etc.), you will need to make changes to that file. This page describes the basics of that process.

Setting and overriding properties

You can change properties by editing properties-local.xml. That file goes in the directory WEB-INF/resources/config, inside the Orbeon Forms web app.
If that file doesn't exist yet in your installation of Orbeon Forms, you can create it by renaming or copying the file properties-local.xml.template into properties-local.xml. At this point, your properties-local.xml will only contain an opening <properties> tag and closing </properties> tag, and you'll want to edit it to add properties between those two tags, as in:
1
<properties xmlns:xs="http://www.w3.org/2001/XMLSchema"
2
xmlns:oxf="http://www.orbeon.com/oxf/processors">
3
<property as="xs:string"
4
name="oxf.fr.persistence.provider.*.*.*"
5
value="oracle"/>
6
</properties>
Copied!

Documentation for specific properties

Each Orbeon Forms subsystem defines its own properties. They are documented in the following pages:

What's in a property

A property is made of:
    a type, such as xs:boolean
    a name, such as oxf.resources.versioned
    a value, such as true
    optionally, and rarely, a processor name, such as oxf:page-flow, which refers to an XPL processor name
This is typically put together like this in properties-local.xml:
1
<property
2
as="xs:boolean"
3
name="oxf.resources.versioned"
4
value="true"/>
Copied!
Some properties support wildcards, for example:
1
oxf.fr.persistence.app.uri.*.*.*
Copied!
You can also place longer property values inline [SINCE Orbeon Forms 4.6]:
1
<property as="xs:string" name="oxf.fr.detail.process.save-final.*.*">
2
require-uploads
3
then validate-all
4
then save
5
then success-message("save-success")
6
recover error-message("database-error")
7
</property>
Copied!
Changes to most properties are taken into account as soon as you save your property file (e.g. properties-local.xml), however changes to some properties are only taken into account when the server is first started.

Categories of properties

Properties fall in two categories:
    standard, which means they are defined by Orbeon Forms
    custom, which means they are defined by form authors, administrators or integrators
All standard properties have standard values defined in built-in property files, described in the pages linked above, and can be overridden when needed.
In general, here is how you deal with properties:
    you look up the documentation for a given property
    if needed, you set or override the property in properties-local.xml

Wildcards in properties

Property names may be defined using wildcards. A property name is assumed to be built as a series of path elements separated by . characters. A path element may contain a * character instead of an actual path element value.
1
<property
2
as="xs:anyURI"
3
name="oxf.fr.persistence.app.uri.*.*.*"
4
value="/fr/service/exist"/>
5
6
<property
7
as="xs:anyURI"
8
name="oxf.fr.persistence.app.uri.*.*.data"
9
value="/fr/service/oracle"/>
10
11
<property
12
as="xs:anyURI"
13
name="oxf.fr.persistence.app.uri.orbeon.builder.form"
14
value="/fr/service/resource"/>
Copied!
In this example:
    If the property name oxf.fr.persistence.app.uri.orbeon.builder.form is requested, the value /fr/service/resource is returned (exact match).
    If the property name oxf.fr.persistence.app.uri.orbeon.foobar.data is requested, the value /fr/service/oracle is returned, because the path elements orbeon, foobar match wildcards, and data matches the last path element.
    If the property name oxf.fr.persistence.app.uri.orbeon.foobar.form is requested, the value /fr/service/exist is returned, because the path elements orbeon, foobar and form all match wildcards.
This allows creating hierarchical properties with generic defaults and more specific values.
In general these are used with Form Runner or Form Builder and in these cases:
    The first wildcard matches a forms "application name"
    The second wildcard matches a forms "form name"
There is a precedence order with wildcards:
    1.
    an exact match is checked first and always wins if found
    2.
    a wildcard match is done then, starting from the left
So:
    foo.bar wins over *.*, *.bar, and foo.*
    foo.* wins over *.bar

Built-in property files

The default values for those properties are provided in the following files, which are stored in orbeon-resources-private.jar:
    config/properties-dev.xml
      root of dev mode properties
    config/properties-prod.xml
      root of prod mode properties
    config/properties-base.xml
      base Orbeon Forms properties
    config/properties-xforms.xml
    config/properties-form-runner.xml
    config/properties-form-builder.xml
    In general, you shouldn't modify these files.

Properties types

Properties have a documented type, which must be one of the following:
    xs:string
    xs:boolean
    xs:integer
    xs:anyURI
    xs:QName
    xs:date
    xs:dateTime
    xs:NMTOKENS

Defining your own properties

In addition to the standard properties, you can define your own properties. You can then access them from:
    XPath expressions in XForms with xxf:property().
    XPath expressions in XPL with p:property(), where the prefix p is mapped to the namespace http://www.orbeon.com/oxf/pipeline.
    XPath expressions in XSLT with pipeline:property(), where the prefix pipeline is mapped to namespace java:org.orbeon.oxf.processor.pipeline.PipelineFunctionLibrary.
In all cases, for security reasons, those functions won't return the value of properties that contain the string "password" in the name of the property.

Different properties for dev vs. production

In general, you can define all your custom properties in properties-local.xml. However, if the value of a property needs to differ depending on the environment, e.g. the value is different for dev and prod, then you can define those properties twice, in properties-local-dev.xml and properties-local-prod.xml, and have different values defined for the property depending on the file. In that case, you would still keep your custom properties that don't differ depending on the environment in properties-local.xml.
    Properties you define in properties-local-dev.xml apply in dev run mode only, and in that case override properties in properties-local.xml.
    Properties you define in properties-local-prod.xml apply in prod run mode only, and in that case override properties in properties-local.xml.

For contributors: properties subsystem initialization

The properties sub-system is initialized after the Resource Manager (the properties being read like any other Orbeon Forms resources). By default, the following top-level URL is loaded:
    web app in prod mode: oxf:/config/properties-prod.xml
    web app in dev mode: oxf:/config/properties-dev.xml
    command-line: oxf:/properties.xml
Property files support inclusions via XInclude. This is the mechanism used by Orbeon Forms to load all the secondary property files.
Last modified 1yr ago