CoreMedia DXP Release Notes, Version 7.5.45-10
2.2. Improvements and Changes | 2.2.24. Release 7.5.22

Due to the design of the Spring Framework and the CoreMedia CMS, it is necessary to declare many <import/> elements in Spring configuration files, often pointing to the same resource. This slows down the startup of the ApplicationContext.

Unfortunately, org.springframework.beans.factory.xml.XmlBeanDefinitionReader does not track imported XML files, so redundant <import/> elements will lead to Spring parsing the same XML files over and over again (in most cases, those XML files will contain more <import/> elements leading to even more parsing, ...) After moving to Servlet 3.0 resources, for each <import/>, the Jar file containing the XML file has to be unpacked. Also, every time that an XML file is completely parsed, Spring reads all Bean declarations, creates new org.springframework.beans.factory.config.BeanDefinition instances, overwriting any existing BeanDefinitions for the same bean ID.

This release introduces an optional system property skip.redundant.spring.imports that is false by default. If set to true, the first <import/> element will be used and all following, duplicate <import/> elements pointing to the same resource will be ignored. The time saved depends on the number of duplicated <import/> elements.

Even though this setting is recommended, it may change the BeanDefinitions that are loaded. (As explained above, normally, BeanDefinitions may be overwritten by subsequent imports, depending on how <import/> elements are used in a webapp).

The PlainTextSerializer is used to strip all RichText-related XML tags from a Markup and only print out the character content. This character content in turn may be XML source code or any other kind of text, which is not interpreted by the CMS. When using the PlainTextSerializer to print the content on an HTML page, the content is interpreted as HTML by the browser if not escaped. While this may be intentional in certain cases, this poses a security risk.

For example, it was possible to write a <script> tag containing JavaScript into any Markup property and have the browser execute this JavaScript. The Blueprint uses this feature in a controlled manner to allow users to add HTML content to the page (See CMHtml/ScriptSerializer/ScriptView).

The behavior was changed to be secure by default, the plain text returned is now escaped. So for example a < is returned as <. To restore the old behaviour, use PlainTextSerializer#setEncode(false)

An option was added to cm serverexport for efficiently exporting content repositories that contain the same blob multiple times, which is then stored on disk only once. This is useful, for example, when multiple translations of a web site are present in the content repository, which contain copies of the same blobs (images etc.). Space requirements on export thereby correspond to space requirements in the content repository, where blobs are always deduplicated. The generated export format corresponds to that used to ship the blueprint example content.

For further details, please consult the section about serverexport in the CoreMedia Content Server Manual.

In addition to various bugfixes, the behaviour of the cm bulkpublish tool has changed slightly. When the --approve-versions option is given to the cm bulkpublish tool, it only approves the latest (checked-in) version. The tool used to also approve any other versions newer than the latest approved version, or in the case of new documents, all versions. This results in a performance improvement when dealing with large content repositories due to a simpler query and less approval operations.

Apache Solr has been updated to version 4.10.3.

The CoreMedia Search Engine index configuration has been separated into distinct configuration sets and cleaned up. The directory <solr-home>/configsets contains config set subdirectories content, cae and elastic for Content Feeder, CAE Feeder and Elastic Social indices. Each type of search index has its own index schema (schema.xml) and index configuration (solrconfig.xml). Index fields and settings that are only needed for Content Feeder indices have been removed from the config set for CAE Feeder indices, and vice versa.

Unused field types have been removed from the schema.xml files to keep them simple and avoid unnecessary overhead.

The index schema for Content Feeder indices defines all fields with attribute stored="true" to allow partial document updates. Note that this change leads to larger index files. You can change the definition of the largest field textbody back to stored="false" in <solr-home>/configsets/content/conf/schema.xml to reduce the index disk size, if needed.

The actual index data files are no longer written to the directory configured with JVM system property solr.data.dir. Each Solr core has its own directory now below the Solr Home directory, which also contains the index files. For example, the data files for the studio index are written to <solr-home>/cores/studio/data. The Solr web application needs write access to its Solr Home directory.

The [CoreMedia Search Manual] describes the new configuration in section "Solr Home Directory" in more detail.

Index schema changes make it necessary to reindex Content Feeder and CAE Feeder indices.

The class com.coremedia.cap.user.CapAuthenticationProvider.CapUserAuthority has been removed in the course of the new SSO integration feature.

A Content Security Policy is introduced in order to mitigate Cross-Site Scripting vulnerabilities. The default policy header considers existing preview configuration and includes frame-src whitelisting values accordingly.

The applied policy can be customized or disabled via a set of studio.security.csp.* properties in the application.properties file. For further details please refer to the security chapter of the Studio developer manual.

The wildcard format of the studio.previewUrlWhitelist property in the in application.properties has changed. All URLs must be valid Content Security Policy source values.

Existing Studio blueprint code was adjusted to comply with Content Security Policy.

The following blueprint classes were changed:

The following files were removed from the taxonomy-studio-plugin:

The cspHeaderFilter was added to the studio-webapp web.xml.

The blueprint jangaroo-libs version was bumped to 2.0.10.

The SimpleSearchWidget restricts its searches to the preferred site now. This default can be overridden by setting the the config option preferredSite to false.

The PreferencesUtil class no longer tries to store undefined values as a substruct. The undefined property is cleared instead.

The method com.coremedia.cms.editor.sdk.IEditorContext#setAfterLogoutHandler() has been removed in the course of the new SSO integration feature.

The second (optional) parameter of the method com.coremedia.cap.common.CapLoginService#retrieveSession() has been removed in the course of the new SSO integration feature.

Elastic Social uses Apache Solr as search engine for users and comments now. A separate ElasticSearch installation is no longer required and ElasticSearch is not supported as search engine anymore.

Users and comments are indexed into separate Solr indices. In the Blueprint, Solr maintains indices blueprint_helios_comments and blueprint_helios_users for comments and users of the tenant helios.

Elastic Core applications connect to Apache Solr as configured with property elastic.solr.url. See the [CoreMedia Elastic Social Manual] for configuration options.

Elastic Social content needs to be reindexed into Apache Solr. See the [CoreMedia Search Engine Manual], section "Reindexing Elastic Social indices" for necessary steps.

Determining the current tenant for Studio and CAE applications is now based on TenantLookupStrategies. See below for changes in the default Blueprint behavior.

The e-Commerce API was prepared to support multiple shop systems simultaneously with a single CoreMedia system. Such shop systems can even come from different manufacturers. In principle a concept of a commerce connection was introduced similar to the UAPI CAP connection that is used to connect to the CoreMedia content server. A commerce connection can be defined per site and it describes a certain shop connection endpoint. The connection details are vendor specific (an IBM WebSphere Commerce Server system has obviously other connection properties than a system from another vendor). From the connection you will get all vendor specific service implementations, like the CatalogService.

The module and the package structure of the e-Commerce API were changed. A new introduced base module gathers various classes that can be reused to implement the API against another shop system vendor. The new package structure is more "service driven", that means there is a new package pricing where all pricing related service interfaces and classes are gathered together.

All API service calls have no more context parameters (store context and user context). The commerce contexts will be initialized together with the connection and used for all service calls in that session (within a request).

All API service calls that use external or technical identifier were removed. You will use the long version of the IDs instead consistently. To produce such an ID a CommerceIdProvider can be obtained from the connection.

As for other document types it is possible to create External Pages with a special "Create Content" dialog within the favorite bar. Additionally it is added in menubars and context menus in the e-Commerce library if a category is selected. The category link is then pre-filled with the currently selected shop category. The default location to store the new document is the Navigation/Categories folder of the site.

Settings of the CoreMedia Content Connector running in the IBM WCS can now be loaded from a properties file (the path is specified in the web.xml file). Previously it was only possible to load these settings in the web.xml file directly. This approach is more flexible when using the same application archive for different systems (eg. for test, staging and production). The web.xml file can remain unchanged.

The view type property field is hidden when there are no applicable view types for the document that is being edited. This makes it easier to provide reusable document forms that adapt to the settings of the current site. This behavior has been enabled in the ViewTypeSelectorForm by setting the config option hideForSingleChoice of the ViewTypePropertyField.

The previous solution of determining the tenant based on prefixes of the server URL is no longer recommended. Instead, the default strategy for the Blueprint relies on the context settings for Elastic Social. For each Site's root channel, the tenant property needs to be set. For more details, we refer to the section Configuring Elastic Social of the [CoreMedia Elastic Social Manual].

When developing templates, developers start a local Tomcat. Up until now, templates would only be read from the workspace if no templates were uploaded to the ContentServer. Now, the CAE will use the Spring property cae.use.local.resources to determine whether to read templates from the workspace or (potentially) read them from the ContentServer.

A new customizer addRepositoryTemplateLocationPattern was added to blueprint-views.xml that can be enabled by setting cae.use.local.resources to false.

The cae-preview-webapp module will read templates from the workspace by default because cae.use.local.resources is set to true. Deployed webapps will read templates from the ContentServer by default because cae.use.local.resources is set to false.

The Blueprint classes ReferrerListPanel and ReferrerListPanelBase have been moved into the package com.coremedia.cms.editor.sdk.premular of the Studio core module editor-components. They are public API now.

The Blueprint class SiteUtil has been moved into the package com.coremedia.cms.editor.sdk.util of the Studio core module editor-components. It is public API now.

The deployment properties SOLR_MASTER_DATA_DIR and SOLR_SLAVE_DATA_DIR have been removed. The actual index data files are no longer written to the directory configured with JVM system property solr.data.dir but to the Solr Home directory.

The Blueprint packages solr-master-tomcat and solr-slave-tomcat are not correctly set up for Solr replication. Nothing gets replicated with the default configuration.

The solrconfig.xml files in the config set directories content, cae and elastic in <solr-home>/configsets use the following variables in the configuration of the ReplicationHander which are not correctly resolved: ${enable.master:false}, ${enable.slave:false} and ${solr.master.url:http://localhost/solr}.

As workaround these properties can be specified as JVM system properties. For the Solr Master Tomcat use -Denable.master=true -Denable.slave=false. For the Solr Slave Tomcat use -Denable.master=false -Denable.slave=true -Dsolr.master.url=http://<master-host>:<master-port>/solr with <master-host> and <master-port> set to hostname and port of the Solr Master Tomcat. Alternatively you can just replace the mentioned ${...} placeholders in all solrconfig.xml files.