Properties

Overview

Orbeon Forms is configured via configuration properties. They are setup in a file called properties-local.xml and stored in the Orbeon Forms WAR file as:

WEB-INF/resources/config/properties-local.xml

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:

<properties xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:oxf="http://www.orbeon.com/oxf/processors">
    <property as="xs:string"
              name="oxf.fr.persistence.provider.*.*.*"
              value="oracle"/>
</properties>

Properties you must configure

You must set the oxf.crypto.password property to something different from the default.

[SINCE Orbeon Forms 2023.1]

Orbeon Forms will cause an error when starting if the default value for oxf.crypto.password is used. This is to prevent you from using the default value in production.

In addition, a password strength checker will also cause an error if the password is too weak. Ideally, use a randomly-generated strong password.

Documentation for specific properties

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

• General properties

• Form Runner properties

  • Detail page

    • Attachments

    • Email

    • PDF

  • Persistence

  • Summary page

• Form Builder properties

• XForms properties

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:

<property
  as="xs:boolean"
  name="oxf.resources.versioned"
  value="true"/>

Some properties support wildcards, for example:

oxf.fr.persistence.app.uri.*.*.*

You can also place longer property values inline [SINCE Orbeon Forms 4.6]:

<property as="xs:string" name="oxf.fr.detail.process.save-final.*.*">
    require-uploads
    then validate-all
    then save
    then success-message("save-success")
    recover error-message("database-error")
</property>

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.

<property
  as="xs:anyURI"
  name="oxf.fr.persistence.app.uri.*.*.*"
  value="/fr/service/exist"/>

<property
  as="xs:anyURI"
  name="oxf.fr.persistence.app.uri.*.*.data"
  value="/fr/service/oracle"/>

<property
  as="xs:anyURI"
  name="oxf.fr.persistence.app.uri.orbeon.builder.form"
  value="/fr/service/resource"/>

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.