Orbeon Forms uses the log4j logging framework. In Orbeon Forms, log4j is configured with an XML file. Here is a sample 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.

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.

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. It is however strongly discouraged to do so, as validation can highly contribute to the robustness of the application.

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. It is however strongly discouraged to do so, as validation can highly contribute to the robustness of the application.

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 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.

Orbeon Forms ships with two implementations of Trace:

• NetworkTrace sends profiling information to Studio. Studio then displays the data in the trace views. When using NetworkTrace, you also need to specify the host and port to which the information is sent to with the processor.trace.host and processor.trace.port properties.
• StdOutTrace simply dumps profiling information to standard output.