The struts:message() function has a new parameters order. The last argument, bundle, moved to the second position to be more user-friendly. Only the first argument is mandatory.

Former Syntax: struts:message('key', 'arg0', 'arg1', 'arg2', 'arg3', 'bundle')

New Syntax: struts:message('key', 'bundle', 'arg0', 'arg1', 'arg2', 'arg3', 'arg4')

Furthermore, the Struts functions are now supported in Saxon 6, Saxon 7 and XSLTC in addition to Xalan.

OXF now supports accessing Software AG's Tamino XML database. Five new processors have been added to query, insert, delete and update XML documents in Tamino. See XML Databases section for more details.

• XSLT 2.0 ? The Web application controller now picks a different engine to execute XSLT stylesheets depending on the version of the stylesheet. For XSLT 1.0 stylesheets, it uses oxf/processor/xslt-1.0 (by default Xalan) and for XSLT 2.0 stylesheets it uses oxf/processor/xslt-2.0 (by default Saxon 7). The defaults can be changed in the processors.xml file. Note that the XSLT 2.0 simplified stylesheets modules are also supported.

• Setting resources MIME type ? With the new optional mime-type attribute on the files element, you can set the MIME type sent to the browser. For instance, with <files path-info="*.java" mime-type="text/plain"/> the Java files will be served with the plain text MIME type, instead of the default text/x-java MIME type.

The HTTP Serializers can add custom headers to the HTTP response.

The LDAP processor now supports the SSL protocol.

You can now skip the Log4J initialization sequence if necessary by omitting the oxf.servlet.log4j property.

• The Java processor example shows how to create a custom processor in Java and use it in a pipeline with the Java processor.
• Create Your Own RSS Feeds retrieves a Web page with the resource generator, selects part of the document with an XPath expression, and creates an RSS feed from the extracted data.
• The Google Spell Checker spell-checks a paragraph of text entered in a form by searching it on Google. The queries are sent to Google with the URL generator.
• The Tamino XML Server example provides a sandbox to experiment with the 5 new processors provided in this version to access Software AG's Tamino XML database.
• The Report in HTML, PDF, and Excel example illustrates how to generate different formats (here an HTML page, a PDF document, and an Excel spreadsheet) from the same XML data.

The format of the mime-types input has changed: the mapping from a file to a MIME type used to be based only on the file extension; it is now based on a pattern, which allows for more flexibility. Note that using <files> elements in the Web application controller configuration is in general preferred over directly calling the resource server processor.

• When the select expression on a <xu:append> returns a node set, the append operation is performed on each node of the node set.
• XUpdate error messages now point to the file, line number and column number involved in the error.
• Relatives URLs in the doc() and document() functions are now supported. When using a relative URL, it is interpreted as relative to the XUpdate program location.
• The position() function now correctly returns the context position when used in a <xu:for-each>.

You can now specify the HTTP headers sent to the server when retrieving a document with the URL Generator.

OXF 2.1 supports Oracle 9i Application Server, version 9.0.3.0.0. Read the installation instructions.

OXF 2.1 introduces the OXF Portlet, a Java portlet following the Java Portlet Specification Version 1.0 (Proposed Final Draft) of August 26, 2003, also known as JSR-168. OXF hides the complexity of the Portlet API to allow most OXF applications to work unmodified within portlet containers and to follow the best practices allowed by the Web Application Controller.

In addition, OXF 2.1 includes alpha versions of the OXF Portlet Container and the OXF Portal.

For more information, please visit JSR-168 Portlets.

Version 2.1 introduces a new construct to perform iterations in XPL. Refer to the Pipeline processor documentation for more information.

The Java processor is significantly enhanced in this version. In particular:

• In previous versions, it did not support custom processors implemented over more than one Java file. This limitation is waived in OXF 2.1: the Java processor can now be used for complex custom processors, or multiple processors that share the same "utility classes".

• The Java processor only compiles the Java files of a custom processor when needed. If the compiled files are up-to-date, no compilation will be performed, even if the Java files were compiled in a "previous session" and the application server has been restarted since then.

• All the custom processors deployed in the same sourcepath (see the Java processor documentation for more details) are loaded by the same class loader. This is more efficient than always creating one class loader per custom processor, as in previous versions of OXF, and allows different processors deployed in the same sourcepath to share state stored in static class attributes.

The config input has been renamed schema. The new config input selects the mode of the validator, either decorating, or not. Read the Validation Processor documentation for more information.

The names ProcessorServlet (Servlet), ProcessorFilter (Servlet filter) and ProcessorServletContextListener (Servlet context listener) in web.xml are now deprecated in favor of OXFServlet, OXFServletFilter and OXFServletContextListener. The old names still work but will eventually be removed.

The following property names in properties.xml have been deprecated:

• oxf.servlet.processor
• oxf.servlet.input.*
• oxf.servlet.context-initialized.processor
• oxf.servlet.context-initialized.input.*
• oxf.servlet.context-destroyed.processor
• oxf.servlet.context-destroyed.input.*

The new names are as follows:

• oxf.main-processor.uri
• oxf.main-processor.input.*
• oxf.context-initialized-processor.uri
• oxf.context-initialized-processor.input.*
• oxf.context-destroyed-processor.uri
• oxf.context-destroyed-processor.input.*

Visit Packaging and Deployment for more information.

In previous versions, there was only a single main processor (often the Web Application Controller processor) for all the components (Servlets and Servlet filters) in web.xml. It is now possible to specify a different main processor and associated inputs for each Servlet, Servlet filter and JSR-168 Portlet. Visit Packaging and Deployment for more information.

The Resource Server MIME Media Type input name has been changed from mime-type to mime-types for consistancy reasons.

As documented in the Pipeline Processor section, you can see processors input and output XML documents by adding a debug attribute on the <p:input> and <p:output> elements. When this attribute is specified, OXF logs the corresponding XML document with Log4j. You can configure Log4j to send this information to Chainsaw, a graphical log viewer bundled with Log4j.

Version 1.2.8 of Log4j is now bundled with OXF and the log4j.xml in the OXF showcase application shows how Log4j can be configured to use Chainsaw. With Chainsaw, you can easily filter log messages and see the messages produced on a remote server.

When encountering a debug attribute in a pipeline, the Pipeline processor inserts a Debug processor. This processor is now explicitly documented and it is now possible to replace it by your own custom debug processor, that may implement a different behaviours than the default debug processor.

The HTML Serializer used to output a default DOCTYPE. This did not allow to generate HTML output with no DOCTYPE at all, which is needed for example to generate HTML fragments for JSR-168 portlets. If you are using the HTML Serializer manually, you have to explicitly set the DOCTYPE in the serializer configuration if you want to output one. The Web Application Controller still outputs a default HTML DOCTYPE. To override it, use your own serializer in your epilogue.

URL Rewriting in OXF has been overhauled with the addition of portlet support, and documented.

Colors must now be always prefixed by the pound sign (#). They used to be only prefixed for colors specified in the chart input, but not the data input.

The Struts Message Resources support is now compatible with Struts 1.1 and allows the user to specify the resource bundle key. See the Struts Integration page for details.

• In XPL, XPointer expressions that reference attributes are not valid. In previous versions of OXF, they used to return an empty node set. The expression aggregate('root', #doc#xpointer(/element/@attribute)) returned the document: <root/>. Starting with OXF 2.1, using XPointer expressions pointing to an attribute generates an error message.
• The XPath expression string(/) used in an XPointer expression always returned an empty string. This was due to a bug in Jaxen, the underlying XPath library. A version of Jaxen that has been patched to fix this issue is bundled with OXF 2.1.

• The xforms-output-prologue attribute was broken in 2.0.0, 2.0.1 and 2.0.2. It now works as described in the Web Application Controller section.
• Forwarding from a first page to a second page with <result page="second-page"/> did not work if the XForms instance of the second page contained duplicate elements. This issue is fixed in OXF 2.1 and it is now possible to do a forward to a page whose instance contains duplicate elements, like:
  <instance><employee/><employee/></instance>

• In the previous version of OXF, the "data" input of the model wasn't used. Starting with this version, if an action is executed, the "data" output of the action is connected to the "data" input of the model. Similarly, if an action is executed but there is no model, then the "data" output of the action is connected to the "data" input of the view.

  This change has a specific repercussion for pages where all the conditions below are met:

  • XForms is used
  • An action is executed and has a "data" output
  • Either:
    • The model is implemented in an XSL file
    • Both conditions are met:
      • The view is implemented in an XSL file
      • There is no model or the model has no data output

  In this specific case, in previous versions of OXF the XSL file was applied to the XForms instance. Starting with this new version of OXF, the XSL file is applied to the "data" output of the action.

• This version introduces <xu:while>, a new construct to loop construct to perform a set operation while a condition is met. See the XUpdate processor section for more details.
• XPath expressions in XUpdate programs can now use OXF URLs in the document() function, for instance: document('oxf:/dir/somefile.xml').
• Namespace prefixes can now be used in XPath expressions. As with XSLT, when a namespace prefix is used in an XPath expression, the namespace must be declared in the XUpdate program on the element where it is used, or one of it ancestors.

The exception page now shows an easier to read, structured stack trace when possible (Java 1.4 or greater). If the feature is not available from the underlying VM, the page reverts to the old behavior.

The documentation has been reorganized so as to be easier to tackle. In addition, the following topics have been added:

• Using the Java Security Manager ? The Java security manager can be used to prevent OXF applications to perform unauthorized operations. The Installing OPS section now documents how to run OXF under a Security Manager.
• Chart Processor ? Documentation for the Chart processor is now provided in the Charts and Spreadsheets section.
• URL Serializer ? Documentation for the URL Serializer is now provided in the Serializers section.
• Debug Processor ? Documentation for the Debug Processor is now provided in the Other Processors section.
• URL Rewriting ? Documentation for the URL rewriting mechanisms in Presentation Server, including portlet support.

The following features are only supported with a JVM 1.4 or higher.

• XSLT 2.0 and XPath 2.0, provided by Saxon 7
• OLAP Processor
• OXF Portal

The OXF Showcase Application includes a new example that demonstrates how to build wizards in OXF using XForms.

The Web Application Controller did not understand configuration files (usually in page-flow.xml) when no <view> element was declared. When no <view> element was declared, a null pointer exception was thrown. This issue is resolved in OXF 2.0.2.

Caching in the XUpdate processor was too aggressive, causing the debug statement on the config input, or upstream in the pipeline on processors leading to this input not to be printed. In some very rare cases, this could have caused an old version of the XUpdate program to be used. This issue is fixed in OXF 2.0.2.

Command line applications using OXF did not work because incorrect JAR files were referenced from the MANIFEST.MF bundled in oxf.jar. This is issue is fixed in OXF 2.0.2.

The URL generator could throw a NullPointerException when using configurations containing only an <url> element and no content-type. This issue is fixed in OXF 2.0.2.

In WebLogic 7, WebLogic 8.1 and Tomcat (with Sun's JDK 1.3), the JAR class loader doesn't know how to determine the last modified date of a resource contained in a JAR file. Under those circumstances, the OXF 2.0.0 cache considers that those resources can not be cached. This problem is fixed with OXF 2.0.1. If you are running WebLogic or Tomcat (with JDK 1.3), you should upgrade to OXF 2.0.1. This upgrade will enhance your application's performance.

When Web applications are deployed on Tomcat in the form of compressed WAR files, and the application resources are stored in the WAR file, OXF 2.0.0 is not able to determine the last modified date of the resources. Consequently, caching was not performed on those resources. OXF 2.0.1 can determine the last modified date of the resources even when they are packaged in a compressed WAR. In this scenario, users will notice that their applications will run much faster with OXF 2.0.1.

The JSF examples now work with Tomcat 4.1.x and WebLogic 7.0 8.1. The version of JSTL that shipped with the JSF Reference Implementation Early Access 4 was not compatible with JSP 1.2. OXF 2.0.1 ships with a version of JSTL compatible with JSP 1.2, supported by Tomcat 4.1.x and WebLogic. In addition, some fixes for WebLogic have been introduced. Please read the updated installation instructions for more details.

Some of the classes exposed by OXF to allow applications to implement custom processors have been moved to new packages. The Processor API section documents the new package names. You should also recompile all your custom processors when switching to OXF 2.0 (or later) to make sure that you are using valid package and class names.

The Web application deployment descriptor, web.xml changed significantly with the 2.0 release. The OXF initialization parameters are now declared in context-param elements instead of servlet/init-param elements. The OXF engine can be used from a variety of sources and the initialization parameters must be accessible from a servlet, filter or context listeners.

The Processor API chapter now explains how to write processors with no output in Java using the OXF processor API.

The Web Application Controller (WAC) is the heart of an OXF Web application. It maps incoming user requests to individual pages and defines how each page is built out of a model and a view, according to the model-view-controller (MVC) architecture. It also defines which XForms model is used for a given page.

In addition to these existing features, the new WAC in OXF 2.0 allows you to declare the entire site navigation logic (also known as page workflow). With a central place where the navigation logic is defined, pages can be developed completely independently from each other. To implement page navigation, the WAC now supports actions and action results.

The new WAC helps you design your Web application with a complete separation between:

• Site Logic: what pages are brought up and when, as well as how navigation happens is orchestrated from page to page.
• Page Logic (the Model in MVC): for example, how data entered by the user is validated and then used to retrieve and update data in a database.
• Page Layout (the View in MVC): how information is laid out in a Web page in order to be presented to the user.
• Site Presentation: layout and look and feel common to all the pages in your Web application or Web site, e.g.: site navigation menus, table backgrounds, or number formatting.

Other improvements to the Web Application Controller include:

• Efficiency - When the configuration changes, the new Web Application Controller is now much faster to recreate the internal structures needed to handle the new configuration. It also uses less memory, allowing for a larger cache size with the same heap size.
• Serializer choice and configuration - By default, the output of the view is sent to the browser with the HTML serializer. It is still the default, but now the epilogue can serialize the output of the view. In this case the epilogue will has no data output. This gives you the full latitude to choose what serializer to use and what its configuration is.

This version of the WAC is backward compatible with the OXF 1.x WAC, meaning that your current configuration file will work out of the box with OXF 2.0.

5.2.1. Custom Attributes

5.2.2. Submit Controls

5.2.3. Examples

5.2.4. Namespaces Support

5.2.5. xforms:label

5.2.6. Form Name

The Servlet Include Generator is used to call a URI within the Servlet container that runs OXF. The URI must return well-formed XML. This processor can effectively implement portlets in conjunction with the Struts/OXF integration.

5.4.1. CLOB Support

5.4.2. Iterations in <sql:param>

5.4.3. Transaction Support

Supports the Early Access 4 implementation of JSF. This allows using OXF to implement a JSF application's look and feel. For more information, visit Using OXF with JavaServer Faces (JSF).

5.6.1. Transformers

5.6.2. URL Generator

5.6.3. Configurable Serializers

5.6.4. Image Server

5.6.5. Request Generator

5.6.6. File Serializer

5.6.7. Validation Processor

5.6.8. Resource Server

5.6.9. URL Resource Manager

• LDAP Processor - Supports querying an LDAP server through JNDI and filtering out the resulting attributes.
• XQuery Processor - Supports transforming XML documents based on the XQuery specification.
• XUpdate Processor - Supports updating XML documents based on the XUpdate specification.
• Chart Processor - Support for charts based on the JFreeChart engine. This processor can either stream images to a client web browser, or save them on disk to allow for caching if the charts are to be reused.
• PDF Serializer - This processor easily converts XML documents to PDF file, utilizing XSL-FO and the Apache FOP library.
• Yahoo Instant Messaging Processor - Support for sending and receiving Instant Messages though the Yahoo service.
• Scheduler Processor - OXF now supports scheduling tasks implemented as XML pipelines. A task can be started, stopped, and executed at a specific time or at a regular interval.
• Initialization and Destruction Listeners - Support for Servlet context initialization and destruction listeners, implemented as XML pipelines.
• Email Processor - Support for sending email messages.
• Excel Import and Export - Support for Excel Import and Export.

The Struts integration has been revamped to include support for Castor 0.9.4.3, Castor mapping files, serialization of any bean, access to ActionErrors and application resources. See the documentation for details.

This version includes new processors:

• The Image Server
• The Resource Server
• The Bean Generator
• The Struts ActionError Generator

This version ships with Apache Xalan 2.5_D1 as default XSLT transformer.

XPL identifiers, used to identify processor inputs or outputs, support "." and "_". They conform to the following regular expression: [_A-Za-z][_A-Za-z\\-0-9.]*.

The SQL Processor supports more column datatypes, including reading XML fragments, and introduces a type notation which is compatible with XML Schema datatypes. sql:get-columns supports the exclusion of selected columns. A new sql:value-of element is implemented. See the documentation for details.

It is possible to specify non-standard attributes to any XForms element using the xxforms prefix. A special element, xxforms:hidden, implements the equivalent of HTML hidden fields. See the documentation for details.

In rare situations, a race condition could cause NullPointerExceptions or other error messages from the Pipeline processor when multiple HTTP requests were handled concurrently. This condition is fixed.

This version features major performance improvements. In particular the Pipeline processor is more efficient. The memory consumption has also been reduced, enabling the cache to store more objects with the same VM heap size.

When a problem occurred in the sample application, a grey page was shown with a copyright notice. The page now displays more information about the error (including a description of the problem, the location where it occurred if available and the Java stack trace), as it was the case in version 1.0.

The log entries include a date. This is an example of the format used:

2003-03-06 10:48:59,939 INFO OXF OXFServlet - /examples/ - Received request

The format can be customized in config/log4j.xml.

The SQL processor correctly supports sql:get-double and sql:get-decimal. In order to be compatible with XPath 1.0, which does not support the scientific (exponential) format, floating-point numbers are output without the scientific format.

The Struts example included in version 1.5 didn't work as expected. This version fixes the issue.

Setting multiple <param> elements in a <page> element works correctly.

Error reporting in the Pipeline processor is improved:

• The Pipeline processor used to generate a NullPointerException in certain cases when an input could not be found; it now correctly reports the missing input.
• When a processor cannot be loaded, for example because its implementation class cannot be found, an error message is issued with the name of the processor and the class name.

The XSLT transformer is fully aware of calls to the XPath document() function in XSLT stylesheets. Assume that we have a transformation including:

• A stylesheet document ( config input)
• An input document ( data input)
• An included document (using the XPath document() function in the stylesheet)

If none of those documents have changed, then the output of the transformation can be cached. But the transformation is always reapplied if the included document has changed.

There was an issue with the Java processor and Tomcat, due to the handling of the temporary directory. This issue is fixed.

• The attribute encoding of the submission element is supported in the XForms model. When present, an attribute enctype will be added to the generated form element. The enctype attribute value is set to the value of the encoding attribute in the XForms model.

• Attributes in the XForms model are now supported. Attributes can be referenced with an XPath expression just like elements.

The preliminary JavaServer Faces integration now works with the Sun Reference implementation version 1.0 Early Access 3 (EA3) of JSF. Version 1.0 Early Access 2 (EA2) is no longer supported.

The Redirect Processor now supports multiple value elements in a parameter element, so as to be consistent with the Request Generator.

OXF version 1.5 supports the following application servers:

• Jakarta Tomcat 4.0 and 4.1
• BEA WebLogic 6.1 and 7
• IBM WebSphere 4 and 5
• Sun SunOne 7

Performance improved considerably in this release. OXF also requires much less memory to run efficiently. These are both consequences of the new cache system (more on this below) as well as many other improvements in the product.

In the Web Application Controller configuration, the xforms, model and view attributes had to point to an XPL document. In this version, XPL, XSLT and regular XML documents are supported. In addition, a new mechanism allows passing URL fragments to the model through the instance using matchers.

The OXF documentation example is now using a matcher in the Web Application Controller configuration file to extract information from the URL. The documentation for this example explains how this new feature can be applied.

The view element in the Web Application Controller configuration has a new optional attribute: xforms-output-prologue. This attribute points to an XSL (or XPL) file which is applied to the view before the XForms elements are transformed into HTML-like attributes.

There are two new processors used to store/retrieve XML documents into/from the session: the Session Serializer and Session Generator.

The HTML serializer is able to send a Content-Length header. The content length is only sent when the complete result is cached.

A new cache is provided with this version. The previous cache used soft references, which was problematic for two reasons:

• Interoperability: not all the Java VMs correctly implement soft references.
• Performance: depending on the value of the -XX:SoftRefLRUPolicyMSPerMB VM parameter (Sun VMs), the soft references were either:
• collected too early, causing many cache fault
• collected too late, drastically reducing the amount of free memory at any time which in turn triggered numerous full garbage collections

The new cache is more efficient and solves the two issues above. You can tune the cache by setting its size.

XSLTC is an XSLT transformer that compiles stylesheets into Java bytecode. XSLTC is part of the Xalan distribution but is not as stable as the standard Xalan XSLT transformer. We do not support the use of XSLTC in this release. The oxf.xslt.transformer property must be set to interpreter.

The Request Generator is now fully configurable. You can define the the subset of the request you are interested in.

The HTML, XML and text serializers are now configurable. In particular, you can set the MIME type, status code and error code sent to the client.

Also, all the HTTP serializers (XML, HTML, text and FOP) will flush their output stream when they encounter the following processing instructions: <?oxf-serializer flush?>. This enables the client's browser to incrementally display a Web page. Incremental display is typically useful when sending large tables or when the first part of Web page can be sent right away, while the rest of the page cannot be sent until a time consuming action is performed.

A new Request Security processor is available, allowing access to security-related information, such as the logged-in user, or the transport mechanism.

Elements in the Web App Controller configuration file must use the namespace http://www.orbeon.com/oxf/controller. With the previous version, there was no namespace declaration.

The XForms namespace changed from http://www.w3.org/2002/xforms to http://www.w3.org/2002/xforms to be consistent with the latest XForms specification. The namespace http://www.w3.org/2002/xforms is considered deprecated. It is still supported in this version for backward compatibility, but might not be supported in future versions of OXF.

Caching of XSLT stylesheet takes into account the included as well as the imported stylesheets (with <xsl:include> or <xsl:import>).

Let's consider a transformation using a stylesheet, style.xsl that includes another stylesheet, utils.xsl.

Creating the internal representation of an XSLT stylesheet, known as a transformer object, is a time consuming process. The OXF cache stores transformers in order to enhance performance. When stylesheet sources change, it is necessary to update the transformer. With OXF 1.0, the transformer was updated only if style.xsl changed, but it was not updated when only utils.xsl changed. This new version updates the transformer if style.xsl or utils.xsl changes, exactly as you would expect it to work.

Preliminary JavaServer Faces integration is implemented. For more information, please read the examples documentation.

New examples are provided in the standard OXF application:

• Shopping Cart demonstrates the new session handling processors
• Authentication> illustrates how access to a page can be restricted
• Address Book shows how to access a SQL database
• JavaServer Faces> shows how to integrate with JavaServer Faces
• OXF Pet Store is an implementation of Sun's Pet Store written 100% with OXF

Version 1.0 used to register processor factories in the JNDI tree. This was an issue with some application servers when multiple OXF applications (e.g. WAR or EAR packages) where deployed on the same application server instance. To solve this problem, this new version uses an internal registry instead of JNDI.