1. New Functionalities for Contributors
1.1 Easier Interfaces
1.1.1 Contextual Menus for Publications
JCMS now makes life easier for contributors by providing some new contextual menus for fast access to the most-used actions on publications (edit, delete, validate, archive, version history, etc.). They also allow rapid consultation of information about publications (metadata, workflow, abstract, etc.). They are available in the front-office and back-office. In the back-office, the contextual menus replace the series of icons visible in last column of the publications lists in previous JCMS versions. To make them appear, click the triangle icon to the right of the editing icons.

Fig. 1. Contextual menu of a publicationn
Each menu is contextual both to the related publication and to the user that calls it up. When actions are not applicable they are grayed. For documents, additional actions are proposed: WebDAV editing (for office documents), locking and preview (for image-type documents and certain office documents).

Fig. 2. Contextual menu of a document
1.1.2 Contextual Menus for Categories
Category tree structures now have contextual menus accessible by right-clicking the category name. The menus enable actions on the selected category (edit, rename, delete, create new categories, add to the caddy, etc.) and provide information (rights, description, associated image, etc.).

Fig. 3. Contextual menu of a category
In addition to the contextual menus, the category trees now support drag and drop. Contributors can reorganize the branches of categories directly via the publications manager or the contribution forms. To move a category branch, click the category icon and drag it to a new parent category.
By combining the contextual editing functions with drag and drop, JCMS 5.7 provides a simple, efficient interface for managing publication categorization.

Fig. 4. Moving categories by drag & drop
1.1.3 Auto-completion
Most link-type fields now have an auto-completion function: instead of choosing a data item to reference via a selection interface, the user just enters a few letters and a listbox appears to propose a list of matching data. Auto-completion operates on various type of fields – publication (content item, portlet, form submission, document), category, member, group and workspace. Fields with auto-completion capability are easily identifiable by their green pale background and a small magnifier icon.

Fig. 5. Auto-completion on a member field
1.1.4 Other Usability Improvements
When a contributor tries to quit an editing form before saving it (for example, by clicking a link or using the "Previous" arrow of the browser), a warning message appears asking for confirmation in order to avoid accidental loss of input data.

Fig. 6. Alert when a contributor quits an Editing Form without saving
Contributors can resize the height of text zone fields; this is automatically adjusted during input.

Fig. 7. Text zones are resizable
Finally, notifications mails are now sent in HTML format (unless a member has opted for text format in his profile).
1.2 Delegation of Rights
Rights delegation enables users to allow other users to use their account. For example, when a validator leaves on vacation he can choose the people authorized to act in its name during his absence.
In his profile editing interface, the user designates the people who can use his account. Users can also see the authorizations they have been delegated by others.

Fig. 8. Declaration of rights delegations
The user can access the list of delegated accounts either by clicking the identification icon or by clicking the triangle to the right of the identification icon.
When a member authenticates himself on a delegated account, a message reminds him that he is using someone else's account. A drop-down menu associated with the logoff icon can be used to move to his own account. All writes (create, update, delete) carried out by users by delegation are traced and appear in the publication histories.
1.3 New rich text editor
JCMS 5.7 has a new rich text editor based on the TinyMCE editor from Moxiecode Systems AB. It is one of the most complete and popular WYSIWYG editors and is compatible with the InternetExplorer 6 and 7 and Firefox browsers. It produces XHTML code. All the functions of the previous WYSIWYG editor are still available and new ones have been added such as insertion of media (video, flash), preview, and resizing of the editing zone. The composition of the icons bars can be changed and new functionalities can be added.

Fig. 9. Interface of the new rich text editor.
1.4 Enriched documentary management
1.4.1 Explicit Version Management
JCMS proposes natively a history of changes made to publications. With JCMS 5.7, users can act on this history, stating for each modification whether it is a minor or major change. This choice is made when saving (the default behavior is configurable):

Fig. 10. Choice of change type (major / minor) when saving
The history of changes highlights major modifications made to publications and modifications associated with the merge of a Work Copy.

Fig. 11. History of a content item: version numbers and merges of Work Copies
With each major version of a publication the date of last major version is updated. This new date can be exploited like any other dates available on a publications (creation, modification, publication, expiry, archive). For example, it becomes possible to configure a Query/Foreach Portlet so that it presents the content sorted by major modification date.

Fig. 12. Choosing sorting by major modification date in a Query/Foreach Portlet
When submitting a new version of a document, the contributor can state whether or not it is a major version.

Fig. 13. Submitting a new major version of a document
Finally, when running the Store Cleaner, the administrator can choose to clear all minor modifications and keep only major versions.

Fig. 14. Possibility of purging minor modifications during store cleaning
1.4.2 Document Locking
Since JCMS v4 is it possible to know if another user is editing concurrently the same publication; if this is the case, the icon appears. However, for documents this functionality is not very suitable since the user would generally prefer to lock the file rather than the file's associated metadata.
To meet this need JCMS 5.7 introduces document locks which allow users to lock a document on which he intends to work. As long as the document is locked, only this user can edit it (by WebDAV) or update it (by saving the new version). Other people can nevertheless continue to download the current version of the document. When the user has finished his work, he unlocks the document to the make it editable again by others.

Fig. 15. Locking a document via the contextual menu
Locking and unlocking
is done either via the contextual menu or via the publication's sheet. The icon
is used to send a release request to the user who locked the document.

Fig. 16. Document locking indication
A workspace administrator can know all the documents locked within his workspace by consulting the Data Report.

Fig. 17. List of locked documents in the workspace report
1.4.3 Support of Open Office and OpenXML Documents
JCMS 5.7 extends its management of office documents by adding support for Open Office (text, table, presentation, graphic and formula) and OpenXML (Word, Excel and PowerPoint 2007) formats.
JCMS automatically recognizes these formats and presents a preview of the document content.

Fig. 18. Preview of an OpenXML document via the contextual menu
1.4.4 Support of Flash Video
The Flash Video (FLV) format has been made popular by video sharing websites such as YouTube and Dailymotion. JCMS 5.7 supports Flash Videos and now features the Jeroen Wijering FLV Player as its Flash Video reader. This reader is used in the Media Browser and for detailed display of documents. It is also used to play MP3 files.
For the moment , Flash Videos can not be included in Rich Text Area or "simple text" (or Wiki text) fields. A plugin to add this functionality is under development. In JCMS 5.7, Flash Videos can therefore be integrated only via media fields.

Fig. 19. Flash Video (FLV) reader
1.5 Express Validation
JCMS 5.7 simplifies the validation of content by providing a validation interface directly in the preview template of the content.

Fig. 20. Validation interface from the contextual preview
1.6 Multilingual Features Extended to Types and Workflows
Previous releases of JCMS already included some sophisticated multilingual support (multilingual content, support of all character sets, etc.).
JCMS 5.7 completes its internationalization by integrating all the textual parts of the publication types (labels, description, etc.) and workflows (labels, states, roles) which can now be input in all the languages of the site.
The date input format is now the one corresponding to the user's language.

Fig. 21. Text fields of types and workflows (label, description, etc.) are multilingual
1.7 Members' Photos
A photo field has been added to members' profiles. A property is provided to authorize or prevent members from adding their photo themselves when editing the profile. The recommended format is JPEG, but GIF and PNG are also supported. The recommended size is 140x180 pixels (JCMS resizes if necessary).
By default the photos appear in the profiles, in the Members List (detailed view), in publication reader lists, in members' contextual menu and in the forum.

Fig. 22. Display of member photos in the forum
1.8 Categorization of Forum Discussions
When a forum is categorized, JCMS propagates this categorization to the discussions composing it. If the categorization of the forum changes, the discussion categorization is updated.
1.9 Draft Workflow
JCMS 5.7 now always proposes a "Draft" workflow which is a very simple form of workflow enabling a contributor to prepare a document for publishing, but without a validation stage.
1.10 Display Template Preview
Note: this function is available from JCMS 5.7.2
To help the user choose a template and a skin for a portlet, a preview is now available when editing it.

Fig. 23. Display template preview for a query/foreach portlet.
1.11 Comparing work copies
Note: this function is available from JCMS 5.7.1
From JCMS 5.7.1, it is possible to compare the work copy of a publication with its original version by selecting "Compare with the original…" in the contextual menu. This enables validators to identify more rapidly the modified parts that need to be checked.

Fig. 24. Compare a work copy with the original publication.
1.12 Massive submission of documents using a Zip archive
Note: this function is available from JCMS 5.7.3
JCMS 5.7.3 enables massive submission of documents by using a Zip archive. To do this, place the files in a ZIP archive using a utility such as WinZip, WinRAR, 7-Zip, etc. Then use the content manager or the Media Browser to submit this archive file. Select the Zip archive and check the "Decompress the Zip files" option. The Zip file is decompressed and JCMS will generate as many documents as there are files in the Zip archive, whatever the tree structure. The result is just the same as if these documents were filed one by one; all the usual controls are activated (quotas, RightPolicyFilter, DataController, StoreListener, etc.). If rights or categories have been selected during the submission, these will be applied to each document. This option is activated by default in the Media Browser.
This option must be used with care. It can be deactivated by setting the file-document.allow-unzip
property to false
.

Fig. 25. Massive document submission using a Zip file.
1.13 Portal home page
Note: this function is available from JCMS 5.7.3
In JCMS 5.7.3, the


Fig. 26. Menu used to go to the workspace of the corresponding portal.
2. Administration and Operation
2.1 Monitoring
The previous interface for monitoring memory consumption is replaced. Apart from the memory consumption, the new display shows, for a given period, site reboots, accesses (queries and sessions) and the number of objects in the Store. All this information is now persistent and is no longer lost during restarts. The persistence window is parameter-defined (monitoring.history-day
).

Fig. 24. New monitoring interface
2.2 LDAP Group Synchronization
JCMS 5.7 enhances the integration of LDAP enterprise directories by synchronizing LDAP groups and the users composing them. Since group management is specific to each LDAP Server, JCMS adapts to the form of the directory.
JCMS LDAP configuration interfacing has been completed to support groups. Pre-configurations are proposed for leading LDAP servers (ActiveDirectory, OpenLDAP, Sun Directory).

Fig. 25. LDAP configuration interface
Groups are synchronized either during the synchronization of members or when groups are imported. JCMS groups include two new fields: the DN (Distinguish Name) of the corresponding group in the LDAP directory and a Boolean item that indicates whether or not this group should be synchronized. JCMS groups synchronized with LDAP are identified by a special icon ().
This mechanism now makes it possible to import a whole series of LDAP accounts into JCMS. To do this, just create in JCMS a group corresponding to the LDAP group to be imported with the DN of this group then trigger the synchronization using the "Synchronize with LDAP…" button. During this synchronization the sub-groups and attached members will be imported into JCMS.
2.3 Store Backups
JCMS incorporates a system to save the Store regularly. Nevertheless, a rigorous system to back up the JCMS site regularly (store, types, workflows, documents, properties, etc.) must be maintained. The objective here is to ensure a minimum backup of the Store to cover extreme events (e.g. a defective external backup). This backup system is active by default, but it can be deactivated (Advanced tab of the Properties Editor).
The backup includes three parameters:
- Backup planning (
store.backup.schedule
). By default, every day at 03:00h; - Number of backups to preserve (
store.backup.max
). By default, 10 backups - Backups folder (
store.backup.dir
). By default,WEB-INF/data/backups/
.
2.4 Contextual Menu for Members
In addition to the contextual menu on publications or categories, JCMS 5.7 now has them on members too.

Fig. 26. Contextual menu of a member
2.5 Plugin Manager
This manager is used to install, configure, and activate/deactivate JCMS plugins that provide particular functionalities (e.g. a new portlet, a blog, a podcast, etc.). Such plugins may be proposed by Jalios or by other players (publishers, integrators, users, etc.). Each plugin has its own usage license.
JCMS plugins can be found on the JaliosXperience site: http://support.jalios.com/plugin/
The Plugin Manager interface displays new plugins distributed via JaliosXperience:

Fig. 27. Plugin management interface
Some functionalities found in earlier JCMS versions have been converted into plugins. To recover these functions you must install the corresponding plugin:
- Cloud Portlet: portlet that displays a cloud of categories;
- Dublin Core: add DublinCore metadata to publications' pages;
- MetaDataExtractor: extraction of PDF metadata;
- SQL Query Portlet: display results of an SQL query;
- Dev Tools: tools for JCMS developers.
2.6 DeployManager
The DeployManager is used to obtain the copy of a webapp and deploy the changes made on this copy. In the past DeployManager had to be installed in a sibling folder of the one containing the webapps to be managed. For some application servers (e.g. Websphere) this required grouping of the webapp and DeployManager in an EAR archive, which complicated the deployment process.
To meet this need, DeployManager can now manage webapps regardless of their location. Just indicate via the property deploy-mgr.webapps
the list of paths of the webapps.
Note: for reasons of consistency, the property that activates DeployManager has been renamed deploy-mgr.enabled
(formerly channel.dm.enabled
).
2.7 Import/Export
Note: this function is available from JCMS 5.7.2
JCMS 5.7.2 provides a new function to import and export content based on an open XML exchange format. A JCMS site can import content from other partner sites. The imports can be made on demand or even be planned. The protocol handles incremental imports, updates, conflicts, and the import of categories and attachments associated with the imported content.
This mechanism allows site designers to employ new decentralized architectures for JCMS. For example, written content validated on the intranet site can now be exported automatically to the Internet site. In a decentralized organization content produced on a common site can be imported by many different sites.
JCMS 5.7.3 incorporates some new import options. It is now possible to state whether the attached categories and files will be imported. You can also ask for markers to be placed in the store before and after the import, in order to rapidly identify the operations relating to an import. Finally, an option is provided to consider imported publications as local publications (e.g. during a migration of content).
The article JCMS 5.7: Implementing Import/Export (in french) describes how to rapidly implement imports and exports between two JCMS webapps.

Fig. 28. The Import Manager.
2.8 Choosing the main language of a workspace
Note: this function is available from JCMS 5.7.3
From JCMS 5.7.3 it is possible to choose the default language of a workspace. When creating a publication, the main language is set by default to the workspace's language.

Fig. 32. Choosing the main language of a workspace.
2.9 Stopping contributions in a workspace
Note: this function is available from JCMS 5.7.3
JCMS 5.7.3 allows a workspace to be closed. This prevents all group editing and publication, except for content imports (see section 2.7).

Fig. 33. Stopping writes in a workspace.
3. Technical Evolutions
3.1 Display URLs
In order to improve the referencing of JCMS sites by search engines, the construction of the URLs associated with publications and categories has been reviewed and now contains the publication title. Search engines such as Google increase the classification of a page according to the words present in the URL.
In earlier JCMS versions these URLs took the form /display.jsp?id=identifier
. With JCMS 5.7, they appear as /jcms/identifier/title-of-the-publication
. The URL prefix (/jcms/
) and the format of the textual part (/title-of-the-publication
) are totally configurable. It is for example possible to add the name of a category, the date, etc. These configurations are made using the properties descriptive-url.*
in the file WEB-INF/data/webapp.prop
.
3.2 Segmentation of Archive and Document Folders
In order to support large volumes of documents of the same type (e.g. JPEG images, MS-Office documents, etc.) and archives, the folders containing such files are subdivided into sub-folders (year-month/ and sub-sub-folders if need be).
3.3 Native Indexing
In the past the indexing of office documents was handled by the JCMS Universal application. However, this runs only with Windows, which may make the architecture of the JCMS production environments more complex. With JCMS 5.7, the indexing can be performed natively for popular document types: MS-Office, OpenOffice, PDF, text and HTML. However, JCMS Universal may still be necessary if PDF conversion is required or if other document types must be handled. The File Indexing Plugin is available for download from JaliosXperience.
3.4 Password Encryption in Properties
The passwords contained in the properties (password of the LDAP Server and the SMTP Host) are encrypted before saving. This encryption is not unbreakable but it does prevent illicit users from seeing this information simply by consulting the properties file.
3.5 Compacting JavaScript and CSS Files
In order to improve access performance, JCMS 5.7 includes an option to compact CSS and JavaScript files. When these options are activated, all CSS files and JavaScript files associated with a page are compacted in a single file, which considerably reduces the number of HTTP requests the browser must perform to display a page.
These two options, activated by default, can be switched off in the Properties Editor (Advanced tab).
3.6 Filtering the Events Journal
The events listed in the events journal can be filtered by levels (information, warnings, errors, etc.).

Fig. 29. Filtering of the events journal
3.7 PConfiguring the site for mobiles
Note: this functionality is available from JCMS 5.7.3
From JCMS 5.7.3 the property small-device.home can be used to set the home URL dedicated to mobile browsers (PDA, i-mode, etc.). This ensure that when a browser of this type accesses the root of the site it will be redirected to this URL. The default redirection is to custom/jcms/indexPDA.jsp
.
3.8 JaliosXperience News
In the Admin Area, a new box presents news from JaliosXperience. A parameter is provided to deactivate this feature.

Fig. 30. Affichage des informations issues de JaliosXperience dans l'espace d'administration.
4. New Development Model
4.1 Plugins
JCMS 5.7 introduces an extension mechanism based on plugins, software modules that modify JCMS functionalities: portlet, content type, template, skin, tag, management rules (DataController
, StoreListener
, QueryListener
, AuthenticationHandler
, etc.)
Plugins are intended to bring better "packaging" and deployment of specific developments. For example, during a migration of JCMS versions, in the nominal case all you need to do is recover all the data and all the plugins and deploy them in the new JCMS version.
Plugins also enable people other than Jalios (ISV, VAR, users, etc.) to distribute their own developments. Indeed Jalios encourages developers to encapsulate specific developments on a JCMS webapp in the form of plugins.
A JCMS plugin takes the form of a ZIP archive containing a descriptor, the file plugin.xml
, and all the resources needed to run the plugin. The descriptor file contains both the information on the plugin (name, description, version, dependences, etc.) and deployment rules.
Plugin management is based on the Inversion of Control principle made popular by frameworks such as Spring or PicoContainer. This principle has the advantage of ensuring only weak coupling between plugins and JCMS, which means that plugins can be added and removed very simply without having to compile classes or edit files.
JCMS has been entirely revamped to make it extensible by plugins. Plugins can now operate in most of JCMS's main internal mechanisms such as:
- Authentication management (
AuthenticationHandler
), - Rights management (
RightPolicyFilter
), - Data management (
StoreListener
andDataController
), - Portal management (
PortalPolicy
), - Indexing management (
LuceneSearchEnginePolicy
), - Wiki (
WikiPolicyFilter
) and Wysiwyg (WysiwygPolicyFilter
) field rendering.
Plugins can also be inserted in most of JCMS's interfaces thanks to the principle of points of inclusion, called targets. Several plugins can be inserted in the same target. To insert in a given target, a plugin indicates in its descriptor the JSP file to include. JCMS 5.7 has about forty points of inclusion including:
- HTML page header,
- HTML page footer,
- All boxes in the administration zone,
- Page headers and footers in the Admin Area and Workspaces,
- Reports,
- Before/after each portlet,
- Before/after each skin.

Fig. 31. Display of targets in the Admin Area (in red)
An article describing plugin development in detail is available on JaliosXperience (in french)
4.2 Application Programming Interfaces
4.2.1 New authentication APIs
To enable the injection of authentication rules, the AuthenticationManager
API has been replaced by that of AuthenticationHandler
. This makes it possible to have several chained authentication rules (e.g. LDAP directories, database, SSO, etc.).
An article describing in detail the development of new authentication rules is available on JaliosXperience (in french).
4.2.2 New Upload Mechanism
The management of document uploading has been completely revised in order to facilitate the development of forms with File fields. The uploads are treated upstream of the FormHanlder
via the MultipartFilter
. The files are available via the getUploadedFileList()
method inherited from JcmsContext
.
4.2.3 ExtraDataMap
Note: this function is available from JCMS 5.7.1
All the data managed by JCMS now include a new persistent field, extraDataMap, which enables storage of additional information. Thanks to this mechanism, a plugin can dynamically add new fields to an existing data type. For example, a geolocation plugin could add the longitude and latitudes fields to the Member and Workspace types and to certain content types. The additional extraData data can also be used programmatically. For example, when uploading a document, a DataController could compute an MD5 signature for the file and store it in the document's extraDataMap.
The extraData can, in a sense, be considered to be an alternative to extensions.
The article JCMS 5.7: Developments using ExtraData (in french) gives more details of this new mechanism.
4.2.4 Portlet Collection
Note: this function is available from JCMS 5.7.2
Collection-type portlets (JSP Collection, Row, Column) get a new interface used to name sub-items. This simplifies the composition in the display template. The portlets can be incorporated using their name instead of their index number. It is possible to associate the same name to several portlets to include them together (e.g. Sidebar, Footer, etc.). The portlets are incorporated using the getPortlet() and getPortlets() methods available in the JSP.
Example:
We declare a JSP Collection portlet containing three named sub-items:

Fig. 32. Declaring sub-items of a JSP Collection portlet
In the associated JSP code we include these portlets using their names:
<%@ include file='/jcore/doInitPage.jsp' %>
<%@ include file='/jcore/portal/doPortletParams.jsp' %>
<% ServletUtil.backupAttribute(pageContext , "ShowChildPortalElement"); %>
<%@ include file='/types/AbstractCollection/doIncludePortletCollection.jsp'%>
<% ServletUtil.restoreAttribute(pageContext , "ShowChildPortalElement");%>
<div id='page'>
<div id='feedrss'><%= getPortlet(bufferMap,"feedrss") %></div>
<div id='search'><%= getPortlet(bufferMap, "search") %></div>
<div id='content'><%= getPortlet(bufferMap,"fulldisplay") %></div>
</div>
4.2.5 Ajax Development
The AbstractJcmsAjaxContext
class is used to develop Ajax handlers for JCMS easily. This class provides all the context data that may be necessary for the processing to be carried out.
4.2.3 Some New Methods
Class | Methode | Description |
---|---|---|
Data |
getDisplayUrl(…) |
Returns the Display URL of a data object |
Data |
getCaddyComparator() |
Returns a comparator based on the presence of a data item in the caddy |
Category |
performImport(…) |
Imports a branch of categories |
Category |
nameExists(…) |
Tests whether a category exists with the same name under a given branch |
Member |
getPhoto() |
Returns the path of a member's photo |
Member |
hasPhoto() |
Tests whether a member has a photo |
Member |
addGroup() / removeGroup() |
Add/remove a group member |
Member |
getDelegateMemberSet() |
Returns all the members authorized to use this account by delegation |
Group |
isLdapGroup() |
Tests whether a group is one from a LDAP synchronization |
Group |
getLastLdapSynchro() |
Returns the date of the last LDAP synchronization of a group |
Group |
getLdapDN() |
Returns the LDAP DN of a group |
Publication |
getMajorVersion() |
Returns the major version number of a publication |
Publication |
getMinorVersion() |
Returns the minor version number of a publication |
Publication |
getVersionString() |
Returns a publication version (e.g. "2 4") |
Publication |
getUdate() |
Returns the date of the last major modification |
Publication |
getUdateComparator() |
Returns a comparator based on the date of the last major modification |
Publication |
getMergeDate() |
Returns the date of the last merge with a Work Copy |
FileDocument |
hasStrongLock() |
Tests whether a document has a lock |
FileDocument |
getStrongLockDate() |
Returns the date when the lock was placed |
FileDocument |
getStrongLockMember() |
Returns the member who placed the lock |
FileDocument |
getUploadDate() |
Returns the date of the last file upload |
FileDocument |
getLockedDocumentSet() |
Returns all the documents having a lock (filtered by workspace and by member) |
JcmsUtil |
getDisplayUrl(…) |
Returns the display URL of a data object (this has more options than the Data class method) |
4.3 New Tags
4.3.1 <jalios:link> Tag
This new tag produces a link with the display URL of a data object (publication, category, etc.). In the JSP the line:
<a href='display.jsp?id=<%= pub.getId %>'><%= pub.getTitle(userLang) %></a>
is now replaced simply by:
<jalios:link data='<%= pub %>' />
It can be used as a body tag:
<jalios:link data='<%= pub %>' >See the publication</jalios:link>
4.3.2 <jalios:url> Tag
This tag is similar to the previous one but produces only the URL (without the <a>
tag).
Example:
<jalios:url data='<%= pub %>' />
4.3.3 <jalios:edit> Tag
This tag has been modified to make it usable as a body tag. It is now possible to use this tag to produce an editing link around a given text (or image).
Example:
<jalios:edit class='Article'>Add an article</jalios:edit>
4.4 New Java and JavaScript Libraries
JCMS 5.7 incorporates the new versions of these libraries:
- JFreeChart 1.0.4
- Prototype 1.5-rc3
- Scriptaculous 1.7
- TinyMCE 2.1.0
5. Technical Remarks on Migrations
5.1 Migration of Publication Types
The recording format of publication types and extensions changes with JCMS 5.7. In previous versions each publication type was associated with an XML file in the folder WEB-INF/data/types
. In JCMS 5.7, a sub-folder exists for each publication type; it contains two XML files:
- a file
MyType
.xml
containing the structure of the type, - a file
MyType
-template.xml
containing the list of the templates of the type.
This separation between structure and template is intended to simplify the migration of JCMS versions.
JCMS converts the old format to the new one automatically at startup. All the old Type.xml
files in WEB-INF/data/types/
are converted then moved to the folder WEB-INF/data/oldTypes/
.
The conversion of existing types (e.g. portlet, article, smallnews, etc.) is handled in a special way: the templates are merged and the structure of the old type is saved in the new folder of the type with the name type-custom.xml.
5.2 Workflow Migration
The format of workflows has also evolved. In previous versions, all workflows were stored in the file WEB-INF/data/workflow.xml
. With JCMS 5.7, workflows are saved separately in the folder WEB-inf/data/workflows/
.
JCMS converts the old format to the new one automatically at startup. The old file workflow.xml
is then renamed workflow.xml.old
.
5.3 Transition to Display URLs
To ensure the benefits of new display URLs (see §3.1), all the JSPs produced from specific developments (for example, type or portlet templates) must be modified. All the links calling display.jsp
directly must be rewritten with the <jalios:link>
and <jalios:url>
tag (see §4.3).
Note that a migration to display URLs is not obligatory. URLs based on display.jsp
continue to operate and are redirected to the new URL format. Nevertheless it is strongly recommended to adopt these URLs for websites.
If you use a web server as a frontal for the application server, Apache for example, the mapping must be declared for the prefix used by the friendly URLs.
5.4 Evolution on Publication Types
5.4.1 Article
The Content field of the Article type has been modified, changing from Text Area to Rich Text Area.
5.4.2 Search Portlet
The Search Portlet (PortletSearch) has a new filter field (query
) used to indicate pre-filtering of the search (e.g. of categories, content types, time interval, etc.). The old field replaceFileDoc
no longer exists. The templates of specific Search Portlets must therefore be updated and existing portlets edited.
5.4.3 PortalInterface
The portal
variable defined by doPortletParams.jsp
is now a PortalInterface
(not Portal
). Templates using this variable are consequently updated. For example, this is the case of the Login Portlet (PortletLogin) templates.
5.5 Compatible Applications Servers
JCMS 5.7 uses the Servlet 2.4 API. An application server compatible with this API is therefore required, such as:
- Tomcat 5.0
- Tomcat 5.5
- Websphere 6
- Weblogic 8
- Resin 3
JCMS 5.7 is no longer compatible with Resin 2 and Websphere 5 applications servers.
5.6 Plugin Development
Some specific developments must be rewritten in the form of a plugin.
Authentication control via the former AuthenticationManager
mechanism must be rewritten with the new AuthenticationHandler
API and declared in a plugin.
Similarly, the invoking of special policies (e.g. rights policy: RightPolicy) must also be performed by declaration in a plugin.
Moreover, the JcmsInit
class should no longer be modified. StoreListener
, DataController
, QueryFilter
, etc. should be added by declaration in a plugin.
Finally, it is strongly advised, if possible, not to update the JCMS JSPs but rather to insert via targets (see §4.1).