Skip to Content

Release Notes for XWiki Enterprise 3.3 Milestone 2

Version 12.3 by Sorin Burjan on 2011/11/24
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.
Contents

Second (and last) milestone release of the 3.3 version.

New and Noteworthy (since XWiki Enterprise 3.3 Milestone 1)

New User Interface for the Extension Manager

Although there's no back-end repository where to search for new extensions yet, the new UI for the Extension Manager is starting to shape up. The previous experimental UI has been replaced by a new category in the Administration dedicated to the extension manager, with three different sections.

em.png

searchextensions.png

showextension.png

Link Checker

It's now possible to check the statuses of all external links found in your wiki.

externallinks.png

FAQ Application

A new FAQ application is now made available (but not bundled by default in XWiki Enterprise):

faq.png

Better support for exporting CJK documents as PDF

CJK characters, shorthand for Chinese, Japanese and Korean, need special fonts not provided in the standard 14 fonts required by the PDF specification, nor in the FreeFonts distributed and enabled by default with XWiki. Starting with this version we also distribute three new free fonts, along with the configuration needed to enable them for their target languages.

cjk.png

Updated the installation process of Workspaces

The Workspace Application requires that an admin provides the initial workspace template (as before), but now it can be anything the admin wants to use as base. The admin only has to rename it to "workspace-template.xar" and attach it to the WorkspaceManager.Install page. The workspace-related pages and settings will be applied to the template automatically.

For Developers

JSR330 Provider Support

XWiki now supports JSR330 Providers.

They are useful for the following use cases:

  • You wish to break a cyclic dependency
  • You wish to lazily get a component instance (instead of it getting injected when your Component is looked up the first time)
  • You wish to control how you return the instance you're providing for. For example you may wish to read the Component Hint from a configuration file and return the instance of the Component matching that Hint dynamically

Component Event Improvements

The registration and unregistration event triggered by a component manager is now perfectly paired. Registering an existing component role and hint now trigger the unregistration event before registering the new component.

New Disposable interface for Components

To prepare the future uninstallation feature of the Extension Manager, singleton components could now implements the Disposable interface. This interface require a single dispose() methods that will be call when a singleton component is unregistered from its component manager. When a singleton component has been created, this could happen in three cases:

  • the component role and hints is explicitly unregistered
  • another component role with same hints is registered and therefore replace the existing component
  • the component instance is explicitly released calling the release function in the manager

Components that require a singleton component should be aware that the instance provided is now subject release and should prevent from accessing a component that have been released. This could be done by observing the registration events of the component manager. The Unregister Event is always triggered when a component is released.

Upgrades

The following dependencies have been upgraded:

  • commons-lang 3.1
  • Groovy 1.8.4
  • LogBack 1.0
  • Selenium 2.13.0
  • SLF4J 1.6.4
  • Maven AntRun Plugin 1.7
  • Maven Shade Plugin 1.5
  • Maven Checkstyle Plugin 2.8

Miscellaneous

  • The Dashboard feature which was part of several applications (XWiki Enterprise Application and Administration Application) has been extracted into in a separate Dashboard Application. There's now a new Dashboard space which is visible in the list of spaces on the XE home page.

Translations

The following translations have been updated: 

Supported Browsers

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

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

Internet Explorer
8
Internet Explorer
9
Firefox
3.6
Firefox
8
Chrome
15

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

Warning

If you're running in a multiwiki setup you'll also need to define the property xwiki.store.migration.databases=all to your xwiki.cfg file or explicitly name all databases to be migrated as in xwiki.store.migration.databases=db1,db2,....

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

Warning

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

Entity references are now immutable

EntityReference (and derived classes, DocumentReference...) has been refactored and are now immutable. This change has been introduced to prevent dangerous issues where a reference hold by an object could be changed by another one. This have a lot of consequences on the reference API and this break the backward compatibility. The following change should be noticed:

  • all setters on EntityReference is now protected and could not be used anymore by any public code. Deriving a reference to render it mutable is hardly discouraged.
  • EntityReference#getChild() has been removed, since a single entity may have more than one child. A EntityReference#getReversedParentChain() method has been added to allow easy iteration from the root entity to their children in a given parent chain.
  • EntityReference#clone() has been removed, a copy-construtor is still available, but is useless since an entity is immutable, there is no need to clone it
  • EntityReference#replaceParent(oldParent,newParent) allow creating a new entity with one of the parent in the parent chain replaced
  • EntityReference#appendParent() allow creating a new entity with an appended root parent, this one is useless on any derived class since the parent chain could not appended in them.

API Breakages

The following APIs were modified since XWiki Enterprise 3.2:

<clirr output here>

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected