Default valuesFor the latest configuration, see properties-base.xml.
Global propertiesoxf.cache.size
Orbeon Forms uses an efficient caching system. Orbeon Forms automatically determines what can be cached and when to expire objects. The cache has a default size of 200, meaning that it can hold 200 objects. This size is reasonable for most applications. A bigger cache tends to make the application faster, but it uses more memory. To tune the cache size, see the suggestions in the Performance and Tuning section. oxf.cache.xpath.size
This property configures the maximum number of compiled XPath expressions to keep in the XPath cache. To tune the cache size, see the suggestions in the Performance and Tuning section. [SINCE: 2010-06-30] The default value is changed to 2000 from 600 previously. NOTE: A profiler run shows that 2000 cache entries takes, for fairly typical XPath expressions, about 5 MB of memory. During development, the following XSLT transformer configuration helps with line number errors. The following values are allowed:
HTTP ClientProxy setupTo configure an HTTP proxy to be used for all the HTTP connections
established by Orbeon Forms, add the following two properties:
By default, the host and port properties are commented and Orbeon Forms
doesn't use a proxy. Some of the use cases where you will want to
define a proxy include:
oxf.http.proxy.use-ssl property to true.SSL hostname verifier[SINCE 2011-05-25] When connecting to an HTTPS server, you can specify how the hostname of the server is checked against the hostname in its certificate. You do so with the following property:<property as="xs:string" name="oxf.http.ssl.hostname-verifier" value="strict"/>The possible values are:
strict). However, you might need to set it to allow-all to be able to connect to a server with a self-signed certificate if the cn in the certificate doesn't match the hostname you're using to connect to that server.State setupWhen Orbeon Forms performs XForms submissions, or retrieves documents in XPL over HTTP, it has the ability to keep state across requests. State information includes:
<property as="xs:string" name="oxf.http.state" value="session"/>
This setting impacts the following HTTP requests:
NOTE: These settings only control how the HTTP client in Orbeon Forms handles cookies and credentials. Headers forwardingWhen Orbeon Forms performs XForms submissions, or retrieves documents in XPL over HTTP, it has the ability to forward incoming HTTP headers. For example, if you want to forward the "Authorization" header to your services:<property as="xs:string" name="oxf.http.forward-headers" value="Authorization"/>NOTE: For security reasons, you should be careful with header forwarding, as this might cause non trusted services to receive client headers. [SINCE: 2011-07-29] Similar to general headers forwarding, cookies can be forwarded. By default, the property is as follows: <property as="xs:string" name="oxf.http.forward-cookies" value="JSESSIONID JSESSIONIDSSO"/>This is typically used to forward session cookies to the same application server. Before this property was available, cookies JSESSIONID and JSESSIONIDSSO were automatically forwarded by default. Be sure to place the main session cookie name first in the list, as special handling takes place with that cookie. NOTE: When a username for HTTP Basic authentication is specified, cookies are not forwarded. NOTE: For security reasons, you should be careful with cookies forwarding, as this might cause non trusted services to receive client cookies.
Stale checkingThis property is tied to the HttpClient stale checking:
By default, Orbeon checks for stale HTTP connections. You can disabling stale connection checking by setting the following property to
false (it is true by default):
Socket timeoutThis property is tied to the HttpClient SO timeout:
By default, Orbeon doesn't set a timeout with HttpClient. Setting a timeout can be potentially dangerous as it can lead to service calls that take longer to run than the timeout you specified to fail in a way that can be unpredictable, as it is possible for your services to sometimes return before the timeout and sometimes after. If, nevertheless, you need to set a timeout, you can do so by adding the following property, e.g. here setting a timeout at 1 minute:
If this property is set to a non-blank value, URLs are rewritten against it.
Example:
Usually Orbeon Forms will use the host, port, and
context name as seen by the browser, e.g.
http://www.mycompany.com/orbeon, to infer how to reach itself when calling service URLs. In some cases, this needs to be changed e.g.:
In those cases, the application server will try to connect to
http://www.mycompany.com/orbeon/... which isn't reachable. To solve those, you can use the oxf.url-rewriting.service.base-uri property to provide a URL for the application server which can be reached by the application server, for instance: http://localhost:8080/orbeon.[TODO: Explain where this property is used.] oxf.url-rewriting.platform-paths
Example:
Example:
Example:
Changing the default value of servlet to wsrp is useful if you deploy Orbeon as a servlet and interact with it from a proxy portlet.NOTE: As of 2011-10-18 builds, this is no longer need as the Orbeon-Container header is used instead. Example:
oxf.url-rewriting. wsrp.context
[SINCE: 2011-09-14]oxf.url-rewriting. wsrp.encode-resources
Epilogue and theme propertiesoxf.epilogue.theme
oxf.epilogue.theme.embeddable
oxf.epilogue.theme.renderer
oxf.epilogue.theme.error
oxf.epilogue.use-theme
oxf.epilogue.output-xhtml
oxf.epilogue.renderer-rewrite
oxf.epilogue.process-svg
|
|
|
|
|
|
Rarely used properties
oxf.log4j-config
| Purpose | Configures the logging system |
|---|---|
| Type | xs:anyURI |
| Default Value | The logging system not initialized with a warning if this property is not present. |
Orbeon Forms uses the log4j logging framework. In Orbeon Forms, log4j is configured with an XML file. Here is the default Orbeon Forms log4j configuration.
If this property is not set, the log4j initialization is skipped. This is useful if another subsystem of your application has already initialized log4j prior to the loading of Orbeon Forms.
Note: You don't usually need to modify this property.
oxf.validation.processor
| Purpose | Controls the automatic processor validation |
|---|---|
| Type | xs:boolean |
| Default Value | Enabled |
Many processors validate their configuration input with a schema. This validation is automatic and allows meaningful error reporting. To potentially improve the performance of the application, validation can be disabled in production environments.
NOTE: It is strongly discouraged to disable validation, as validation can highly contribute to the robustness of the application.
oxf.validation.user
| Purpose | Controls user-defined validation |
|---|---|
| Type | boolean |
| Default Value | Enabled |
User-defined validation is activated in the XML Pipeline Definition Language with the attributes schema-href and schema-uri. To potentially improve the performance of the application, validation can be disabled in production environments.
NOTE: It is strongly discouraged to disable validation, as validation can highly contribute to the robustness of the application.
oxf.prologue
| Purpose | Defines Orbeon Forms processors |
|---|---|
| Type | xs:anyURI |
| Default Value | A default prologue is loaded automatically |
Loads a Orbeon Forms prologue file, where processors are declared. Orbeon Forms is bundled with a default prologue file containing all processors. You can create processors (see the processor API) and declare them in a custom prologue. The custom prologue doesn't replace, but completes the default prologue. It is possible to override a default processor with a custom implementation by binding it to the same URI as the default processor. The following example shows a simple custom prologue declaring an hypothetical processor:
sax.inspection
| Purpose | Enable inspection SAX events |
|---|---|
| Type | xs:boolean |
| Default Value | false |
SAX is the underlying mechanism in Orbeon Forms by which processors receive and generate XML data. Given only the constraints of the SAX API, it is possible for a processor to generate an invalid sequence of SAX events. Another processor that receives that invalid sequence of events may or may not be able to deal with it without throwing an exception. Some processors try to process invalid SAX events, while others throw exceptions. This means that when a processor generating an invalid sequence of SAX events is used in a pipeline, the problem might go unnoticed, or it might cause some other processor downstream to throw an exception.
To deal more efficiently with those cases, the sax.inspection property can be set to true. When it is set to true, the pipeline engine checks the outputs of every processor at runtime and makes sure that valid SAX events are generated. When an error is detected, an exception is thrown right away, with information about the processor that generated the invalid SAX events.
There is a performance penalty for enabling SAX events inspection. So this property should not be enabled on a production system.
Note: You don't usually need to enable this property.
oxf.pipeline.trace.class
| Purpose | Specify the name of a class that implements the interface org.orbeon.oxf.pipeline.api.PipelineContext.Trace |
|---|---|
| Type | xs:NCName |
| Default Value | None |
Orbeon Forms ships with the following implementations of Trace:
org.orbeon.oxf.processor.trace.SystemOutTrace: send the information to the standard output