Release Notes for XWiki Enterprise 4.0 Milestone 1

Version 7.1 by Thomas Mortagne on 2012/03/13

Before upgrading to this version, be sure to have a working backup of your database(s).

This is the first milestone of the XWiki Enterprise 4.0 version (Roadmap). This release brings reduced document database id collision and quite a few improvements and bug fixes.

New and Noteworthy (since XWiki Enterprise 3.5 version)

Extension Manager improvements

Extension Manager

  • Added  possibility to choose on which wiki to install an extension
  • When installing/uninstalling extension or any other background job, the result of the  job executing is stored on the filesystem so that it can be reviewed later. There is no UI to access it yet but it's always possible to access the saved file on filesystem directly.

XWiki Repository

  • Added a button to update an imported extension
  • It's now possible to extend an Extension sheet with custom informations. For example adds "Bundled with" and "Compatibility" fields.

For developers

Extension Manager moved to commons

Everything not not specifically related to wiki is now part of xwiki-commons. That means that anyone can get all Extension Manager features (easy live JAR installation/uninstallation from remote repositories, dependency management, etc.) in any Java application.

Classloader module moved to commons

Mostly been moved as Extension Manager dependency but also useful on it own as a tool to dynamically add new URLs in a classloader at runtime.

New Job module

The code to execute a task in backgroup and provide related progress and isolated log has been extracted from Extension Manager and is now in its own module.

Component related improvements

Role moved from Class to Type

In order to support parameterized role like DocumentReferenceResolver<String>, all the APIs of ComponentManager and Component descriptors has been changed to take Type instead of Class. All the old API are still here and working but deprecated.

ComponentRole is deprecated

You should now use @Role instead of @ComponentRole. The difference is that when using @Role the generic parameters will be taken into account as part of the role while with @ComponentRole the role stay the Class of the component role so be careful when you do this change, it might break everything if you don't want to take into account parameters (that's why a new annotation has been introduced instead of changing the behavior of ComponentRole).

References resolver/serializer and Provider now support parameter type as part of the role

This mean that declaring or injecting a such component no longer require any hint unless you want to provide/inject a variant for the same type.

Here are some example. Instead of:

private DocumentReferenceResolver<EntityReference> resolver

private DocumentReferenceResolver<EntityReference> resolver

private Provider<SomeType> resolver

you will write

private DocumentReferenceResolver<EntityReference> resolver

private DocumentReferenceResolver<EntityReference> resolver

private Provider<SomeType> resolver

All reference resolver and serializer provide static variables with the Type for both String and EntityReference. For example you can write:

DocumentReferenceResolver<EntityReference> resolver = componentManager.lookupComponent(DocumentReferenceResolver.TYPE_REFERENCE, "current")

Bug fixes and improvements

  • XE-1096 The attachment selector should also work with the /edit/ action in 'Inline form' edit mode
  • XE-1105 Default class sheet doesn't display correctly the class title
  • XWIKI-7411 Cannot import a XAR containing %3A in its file name
  • XWIKI-6305 Keep the current user in the administration application when editing user details
  • XWIKI-7462 Improve the Profile breadcrumb to be more user friendly
  • XWIKI-7484 Write a log line in the console instructing the user to open XWiki in a browser

See the full list of JIRA issues fixed in this release.

For Developers

  • XCOMMONS-94 Set the minimum required Maven version (3.0) to build XWiki in the POM
  • XWIKI-7502 Replace notion of Container's ApplicationContext with the notion of Environment
  • XWIKI-7476 Sheets need to be able to display the title of the document they are applied to
  • XWIKI-7526 Enable Infinispan JMX mbeans by default for runtime monitoring of XWiki caches
  • XWIKI-7504 Files within WEB-INF directory readable by using Velocity
  • XE-1108 Provide tomcat5 and tomcat7 based Debian packages


The following dependencies have been upgraded:

  • commons-codec 1.6
  • commons-configuration 1.8
  • commons-io 2.1
  • commons-net 3.1
  • HyperSQL 2.2.8
  • Infinispan 5.1.1
  • Junit 4.10
  • Maven Clover plugin 3.1.4
  • Selenium 2.20

Tested Browsers


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

Migration of database IDs

You need to enable database migration ( to upgrade existing databases to the new identifier format.

This is a major migration affecting almost all rows and relations in the database. I may takes a while before the wiki respond to your initial request when you are migrating a large database. The initial request may even timeout but the database migration continue in the background.

Avoid to interrupt the database migration process and check the current progress of the database migration in the console output or the log file. The progress may be slow, so be patient during document id and object id conversion.

In case of interruption, the migration procedure could be restarted by restarting XWiki, and it will start over where it have been interrupted.

We have taken many precaution to provide a reliable migration procedure, but due to the large changes it made, and this release being an unstable one, you should be really careful and ensure that you keep an appropriate backup until you are sure that your data has been properly migrated.

If you have custom mapped classes used externally, be aware that all internal identifier are now full 64bits longs.

General Notes

If you're running in a multiwiki setup you'll also need to define the property in your xwiki.cfg file if you want to explicitly name some databases to be migrated as the default is now to migrate all databases. Database that are not migrated could not be accessed.

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.

API Breakages

The following APIs were modified since version 3.5:



Get Connected