Release Notes for XWiki 4.2

Version 8.1 by Vincent Massol on 2012/09/27
Warning: For security reasons, the document is displayed in restricted mode as it is not the current version. There may be differences and errors due to this.

This is the release notes for XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager. They share the same release notes as they are released together and have the same version.

This is the third release of the 4.x cycle (Roadmap).

If you're upgrading from an older version and you use the new Distribution Wizard to upgrade your wiki pages you'll notice that it'll ask you to merge all pages that have been modified between your version and XWiki 4.2. This is because currently the Distribution Wizard doesn't know which version you have and thus asks you to perform the merge manually. This operation may take a long time (up to 20 minutes or so). Thus at the moment if you're upgrading from a previous version we recommend that you Cancel the Distribution Wizard and instead Import the new XAR. This problem is reported in this issue and should be fixed in the next release.

New and Noteworthy (since XWiki 4.1)

Extension Manager improvements

Main improvements:

  • Starting with this version you can downgrade an extension. In other words, you can install an older version of an extension even if a newer version is currently installed. This doesn't apply to core extensions, which cannot be uninstalled, upgraded or downgraded individually. In order to downgrade an extension that is already installed you need to search for an older version. Currently this is possible only using the advanced search.


  • From the main wiki of a wiki farm you now have the option to trigger extension jobs (install, uninstall, upgrade, downgrade, etc.) that target all the wikis. For instance, as you can see below, you can install an extension on the entire wiki farm:


  • The log messages have been improved to include links to the affected documents or extensions as indicated in the following image:


  • An administrator of a subwiki can now install XAR extension (as long as it does not require a JAR extension).

Experimental install/upgrade wizard

Accessing a wiki page in view mode after an upgrade or when the database is empty (new install) will trigger a wizard that will allow you to install or update the default set of wiki pages and to upgrade or downgrade the extensions you may have previously installed.

The wizard currently has two steps. In the first step you can see which XWiki distribution you are running and what is its recommended default set of wiki pages (the default user interface). You should install, upgrade or downgrade the UI so that it matches the distribution version.


The step has three possible actions:

  • Skip means 'go to the next step and ask me again after a server restart'
  • Cancel means 'go to the next step and don't ask me again until I change my distribution'
  • Continue, only after the recommended UI version is installed

In the second step you can upgrade the installed extensions. We group them in two categories:

  • extensions that don't work with your current distribution but which have new versions available that are compatible with your current distribution. These extension require an upgrade.
  • extensions that should work fine with your current distribution but which have upgrades available. Upgrading these extensions is optional.


You can refresh the list of extensions by clicking on the Reload button. The Skip and Cancel buttons have the same meaning as in the previous step. The Continue button is available only after the required upgrades are performed.

At the end you'll be redirected back to the wiki page you have accessed in the first place.

Improvements to the Extension Repository Application

We modified the extension sheet to display the release notes for all the available versions of an extension. Check for instance the release notes for the Extended TODO Application:


JIRA Macro

A new JIRA Macro is now part of the Platform but is not bundled by default (you'll need to install it with the Extension Manager). We previously had a Contributed JIRA Macro but we decided that the JIRA macro was a good candidate to have in the Platform and thus supported by the XWiki Development Team. Compared to the older Contributed JIRA Macro, the new Macro has the following advantages:

  • No Programming Rights required
  • Supports issue ordering
  • Supports ability to register new Styles, new Data Sources and new Field Displayers
  • Displays closed issues as Striked-out
  • Written in Java with automated tests


New field types for email and list of pages

Two new types of class properties have been added:

  • The Email type extends the normal String type, adding by default a validation regular expression that should accept only a valid email address
  • The Page type extends the normal DBList type, and allows to select one or more documents from the current wiki

These two new properties are still in development, and further improvements will be implemented in the next milestone.

Computed class fields

Another new type of class fields adds support for virtual values computed live from other class values, data from the database, data obtained from an external service, or practically any other source of data. These fields are non-editable and aren't stored in the database, since they only provide some wiki content that will be rendered each time such a property is displayed.

Traditionally, this kind of computation would have been written directly in the sheet used to display instances of that class, but putting it in a class field allows easier reuse of the code, since the property will be displayed in livetables, when indexing the document in Lucene, when displaying documents in an index page, and so on.

Improved upload UI

The new HTML5 FileUploader has been integrated in a few places:

  • The standard attachment upload form
  • The Import section of the Administration

See below for more details about this feature.

New logging administration UI

It's now possible to review and modify the log level for all registered loggers.


New Applications Panel

There's now a new "Applications" panel by default in XWiki Enterprise. This panel displays the applications present in your wiki.


Administrators will get a couple of additional links, allowing them to install applications through the Extension Manager, or to create new applications thanks to the App Within Minutes feature.


Note for application developers: your applications can provide their own entries in this menu by declaring a UI Extension.

Chart Macro Improvements

New Content Macro

The new Content macro allows to enter content in any of the supported Syntaxes and thus allows to have content written in various syntaxes. For example, in a page in XWiki Syntax 2.0:

This is in **bold**

{{content syntax="confluence/1.0"}}
This is *bold* too!

Documents Macro improvements

The {{documents}} macro now supports specifying the list of columns to display. For example:

{{documents count="5" actions="false" space="Main" parent="Main.WebHome" columns="doc.title"/}}

would display:


Search improvements

The Lucene index also stores the MIME type of the indexed attachments, allowing to customize the search to only include or exclude attachments of a certain type. The new field is named mimetype and it contains a valid MIME type string, as returned by the container in which XWiki is running. For example, add -mimetype:image/* to a query to exclude all image attachments from the results, or add mimetype:application/pdf to only search inside PDF attachments.

Remember that in case of an upgrade, you have to rebuild the entire index to have this new field for existing documents.

For Developers

New Git Module

A new, optional (i.e. not installed by default), Git Module has been added. It allows to easily perform Git operations from within wiki pages. For example to count all commits for the past year and list all committers who's committed code during this period, you could write in a wiki page:

import org.eclipse.jgit.api.*
import org.eclipse.jgit.lib.*
import org.eclipse.jgit.revwalk.*
import org.gitective.core.*
import org.gitective.core.filter.commit.*

def service = services.get("git")
def commonsRepository = service.getRepository("git://", "xwiki-commons")
// Do a Git pull to get latest commits
new Git(commonsRepository).pull().call()
def finder = new CommitFinder(commonsRepository)

def dateFilter = new CommitterDateFilter(System.currentTimeMillis() - 365*24*60*60*1000L)
def countFilter = new CommitCountFilter()
def authorFilter = new AuthorSetFilter()
def filters = new AndCommitFilter()
filters.add(countFilter, authorFilter)

println "There have been ${countFilter.count} commits in the past year!"
println ""

println "The following committers have participated in those commits:"
authorFilter.getPersons().each() {
  println "* ${} (${it.emailAddress})"

Default custom displayers for Easier customization of the way object fields are displayed

While XWiki allowed to specify a custom display for a given field, it was impossible to change the way field types, such as DateProperty or IntegerProperty, are displayed in general. Now it is possible to define custom displayers at the farm or wiki level, which gives the administrators more power to change the look and feel of the wiki. For example, this allows to use HTML5 input types for dates and numbers, to use custom suggestions for list of users fields, or to always add a validation input for all the password field types.

To use this feature, first you need to compute a type name for your property type. This is obtained from the java class simple name, removing the Class suffix, and lowercasing. For example, for numbers the java class used is com.xpn.xwiki.objects.classes.NumberClass, with the simple name NumberClass, which gives number as the type name. For a database list, we get dblist from DBListClass.

Next, there are three places where a default custom displayer can be defined.

  1. If a document whose name is the type capitalized and suffixed with Displayer exists in the XWiki space in the current wiki, then its content is used as the default custom displayer for that type of property. For example, localwiki:XWiki.NumberDisplayer and localwiki:XWiki.DblistDisplayer.
  2. If a document whose name is the type capitalized and suffixed with Displayer exists in the XWiki space in the main wiki, then its content is used as the default custom displayer for that type of property. For example, xwiki:XWiki.NumberDisplayer and xwiki:XWiki.DblistDisplayer.
  3. If a velocity template whose name is the type suffixed with .vm exists in the current skin, then it is evaluated as the default custom displayer for that type of property. A skin file can be defined in many places, such as an attachment of a skin document, a file in a named skin on the filesystem, or a file in the templates/ directory.

If a specific class property provides custom display code in the XClass, then that code takes priority over an eventual default custom displayer for that property.

As with property custom displayers, when evaluating the display code several objects are placed in the context:

  • name is the name of the property being displayed
  • prefix is the HTML name prefix to append to an eventual input field name, and contains the XClass name, an underscore, the object number, and another underscore, for example XWiki.XWikiUsers_0_
  • object is the object owning the displayed property, an instance of the public com.xpn.xwiki.api.Object class
  • type is the target display type, one of view, edit, hidden or search

New API to manipulate log level

Several method as been added to org.xwiki.logging.LoggerManager to manipulate the log level of registered loggers.

     * Associate the passed logger to the passed log level.
     * @param loggerName the logger
     * @param level the level of the logger

   void setLoggerLevel(String loggerName, LogLevel level);

     * @param loggerName the logger
     * @return the log level associated to the logger

    LogLevel getLoggerLevel(String loggerName);

     * @return all the registered loggers

    Collection<Logger> getLoggers();

New HTML5 File Upload widget

The File Upload widget can enhance HTML input elements of type file to provide an interactive upload UI. It can submit files either automatically when the user selects local files, or after the user presses the container form's submit button.

To use this widget, it is enough to create a new instance of XWiki.FileUploader passing the target input element as the first parameter, and an optional configuration object as the second parameter.

new XWiki.FileUploader(targetInput, {
  autoUpload: true,
  progressAutohide: true



It's now possible by default to add skin extensions located in JAR files. Example usage:


Attachment Picker improvements

It is now possible to specify a different document for the source (and target in case of uploads) of attachments, using the new targetdocname macro parameter.

Extension Manager improvements

  • the custom Maven property <xwiki.extension.features> now accept any number of new lines and white spaces between elements
  • new custom properties added to overwrite standard Maven properties:
    • to overwrite <name>
    • xwiki.extension.summary to overwrite <description>
    • to overwrite <url>

XAR format improvement

It's now possible to indicate the extension identifier right in the XAR package descriptor (package.xml). Among other things this allow standard import UI to find what it currently importing and register it automatically as installed extension if it can be found in the registered repositories during import process.

The XAR Maven plugin automatically take care of adding this information to the generated package.xml for Maven project. If for some reason you need to indicate it by hand you can use the property <extensionId> under the the <infos> element in the package.xml file.

   <name>XWiki Platform - Extension - UI</name>
   <description>XWiki Extension Manager, an application for managing extensions in a wiki.</description>

New UI Extension mechanism (experimental)

We're in the process of allowing applications to insert custom content in pre-defined places in the user interface. A first Extension Point has been defined in the new "Applications" panel, you can read more about this in the UI Extension module documentation.


  • The transformation context have a "restricted" flag to indicate that macros and other transformations should not perform modifications to the database, expensive computations or other potentially harmful operations.  Developers of macros and other rendering extensions should pay attention to this flag.
  • The messageSender macro now accepts 3 parameters that allow you to customize it by overriding the default displayed visibility levels for a message (that a user can choose from), the default selected visibility level and the default value (in case of user or group visibility). More details on .
  • The new experimental Security API that was first released in XWiki 4.0 is now bundled by default in XWiki Enterprise.
  • It's now possible to access root ComponentManager using "root" role hint:
    private ComponentManager rootComponentManager;
  • A Provider has been added to easily access the context ComponentManager (a proxy which choose the right ComponentManager depending on context information like the current user and the current wiki)
    private Provider<ComponentManager> contextComponentManager;
  • The AbstractMockingComponentTestCase testing framework class has been modified. Read the Testing page for more details on how to use it.

Deprecated and Retired projects

<description of deprecated and retired projects>


The following dependencies have been upgraded:

  • Infinispan 5.1.5
  • JDeb 0.11 
  • JGroups 3.1.0
  • Tika 1.2
  • GWT 2.5 RC1
  • Selenium 2.25
  • Prototype.js 1.7.1
  • Jython 2.5.3
  • Pegdown 1.1.0 (used by the XWiki Markdown Parser)
  • Xalan 2.7.1


  • the progress tab is selected by default when you view the extension details if there is a job running (e.g. install in progress) for that extension
  • when there is a merge conflict, the 'Show changes' button updates the changes asynchronously without reloading the entire page
  • attachments of pages installed with the extension manager now have the right author set: the current user instead of the author from the XAR as it used to be
  • the file size of attachments installed with the extension manager is now properly set
  • the installation process is now more robust with respect to the exceptions that can occur while installing a JAR extension with components
  • Document attachments so far have been displayed in the order in which they are returned by the database, which most of the time happened to be the upload date. Starting with this version attachments are displayed ordered by their filename, which makes it easier to find an attachment, but support for selecting a different order (date, size, author...) will be added soon.
  • Uploading attachments with '+' character in their file names using the WebDAV interface shouldn't pose any more problems.
  • It's now possible to use Velocity scripts in the Copyright field in the Administration.
  • The XWiki Installer now fully works on Windows 7. The XWiki Data is now put in the %APPDATA%\XWiki Enterprise <version>\data directory, while the binaries are installed in Program Files.
  • It is no longer allowed to use scripts in comments.  This reduces the security risk from users that only have comment rights.
  • Macro parameters may now contain macro syntax.  Example: {{box title="{{info}}Hello!{{/info}}" }}Lorem ipsum ...{{/box}}
  • Improve OOB support for JBoss AS7:
    • Removed Struts Taglibs completely since we don't use them and some were defined but not made available, causing errors in deployments on JBoss AS7 ()
    • Fixed Logging conflict between JBoss AS and XWiki ()
  • The IRC Bot Application now recognizes XAR import events and when receiving one, it doesn't send subsequent IRC notifications for modified or created documents to avoid spamming the IRC channel.
  • Display the request URL in the IRC channel when the Link Checker bot listener is active and a broken link is found, thus making it easier to reproduce and debug the broken link


The following translations have been updated: 

Tested Browsers

Here's the list of browsers tested with this version (i.e. browsers that we've tested as working - Check the list of supported browsers):

Failed to execute the [velocity] macro. Cause: [The execution of the [velocity] script macro is not allowed in [xwiki:ReleaseNotes.ReleaseNotesXWiki42]. Check the rights of its last author or the parameters if it's rendered from another script.]. Click on this message for details.


Known issues

Test Report

You can check the manual test report to learn about what was tested and the results on various browsers.

Backward Compatibility and Migration Notes

General Notes

You may also want to import the default wiki XAR in order to benefit from all the improvements listed above.

Always make sure you compare your xwiki.cfg and files with the newest version since some configuration parameters were added. Note that you should add so that XWiki will attempt to automatically migrate your current database to the new schema. Make sure you backup your Database before doing anything.

Issues specific to XWiki <version>

<issues specific to the project>

API Breakages

The following APIs were modified since <project> <version - 1>:

<clirr output here>

Get Connected