Documentation

Documentation Menu
Go Back

7.2 Breaking Changes

This document presents a chronological list of changes that break existing functionality, APIs, or contracts with third party Liferay developers or users. We try our best to minimize these disruptions, but sometimes they are unavoidable.

Here are some of the types of changes documented in this file:

  • Functionality that is removed or replaced

  • API incompatibilities: Changes to public Java or JavaScript APIs

  • Changes to context variables available to templates

  • Changes in CSS classes available to Liferay themes and portlets

  • Configuration changes: Changes in configuration files, like portal.properties, system.properties, etc.

  • Execution requirements: Java version, Java EE Version, browser versions, etc.

  • Deprecations or end of support: For example, warning that a certain feature or API will be dropped in an upcoming version.

  • Recommendations: For example, recommending using a newly introduced API that replaces an old API, in spite of the old API being kept in Liferay Portal for backwards compatibility.

Breaking Changes List

Removed Support for JSP Templates in Themes

What changed?

Themes can no longer leverage JSP templates. Also, related logic has been removed from the public APIs com.liferay.portal.kernel.util.ThemeHelper and com.liferay.taglib.util.ThemeUtil.

Who is affected?

This affects anyone who has themes using JSP templates or is using the removed methods.

How should I update my code?

If you have a theme using JSP templates, consider migrating it to FreeMarker.

Why was this change made?

JSP is not a real template engine and is rarely used. FreeMarker is the recommended template engine moving forward.

The removal of JSP templates allows for an increased focus on existing and new template engines.

Lodash Is No Longer Included by Default

What changed?

Previously, Lodash was included in every page by default and made available through the global window._ and scoped AUI._ variables. Lodash is no longer included by default and those variables are now undefined.

Who is affected?

This affects any developer who used the AUI._ or window._ variables in their custom scripts.

How should I update my code?

You should provide your own Lodash version for your custom developments to use following any of the possible strategies to add third party libraries.

As a temporary measure, you can bring back the old behavior by setting the Enable Lodash property in Liferay Portal’s Control Panel → Configuration → System Settings → Third Party → Lodash to true.

Why was this change made?

This change was made to avoid bundling and serving additional library code on every page that was mostly unused and redundant.

Moved Two Staging Portal Properties to OSGi Configuration

What changed?

Two Staging properties have been moved from portal.properties to an OSGi configuration named ExportImportServiceConfiguration.java in the export-import-service module.

Who is affected?

This affects anyone using the following portal properties:

  • staging.delete.temp.lar.on.failure

  • staging.delete.temp.lar.on.success

How should I update my code?

Instead of overriding the portal.properties file, you can manage the properties from Portal’s configuration administrator. This can be accessed by navigating to Liferay Portal’s Control Panel → Configuration → System Settings → Infrastructure → Export/Import and editing the settings there.

If you would like to include the new configuration in your application, follow the instructions for making applications configurable.

Why was this change made?

This change was made as part of the modularization efforts to ease portal configuration changes.

Removed Link Application URLs to Page Functionality

What changed?

The Link Portlet URLs to Page option in the Look and Feel portlet was marked as deprecated in Liferay Portal 7.1, allowing the user to show and hide the option through a configuration property. In Liferay Portal 7.2, this has been removed and can no longer be configured.

Who is affected?

This affects administrators who used the option in the UI and developers who leveraged the option in the portlet.

How should I update my code?

You should update any portlets leveraging this feature, since any preconfigured reference to the property is ignored in the portal.

Why was this change made?

A limited number of portlets use this property; there are better ways to achieve the same results.

Moved TermsOfUseContentProvider out of kernel.util

What changed?

The TermsOfUseContentProvider interface’s package changed:

com.liferay.portal.kernel.util → com.liferay.portal.kernel.term.of.use

The TermsOfUseContentProviderRegistryUtil class’ name and package changed:

TermsOfUseContentProviderRegistryUtil → TermsOfUseContentProviderUtil

and

com.liferay.portal.kernel.util → com.liferay.portal.internal.terms.of.use

The logic of getting TermsOfUseContentProvider was also changed. Instead of always returning the first service registered, which is random and depends on the order of registered services, the TermsOfUseContentProvider service is tracked and updated with com.liferay.portal.kernel.util.ServiceProxyFactory. As a result, the TermsOfUseContentProvider now respects service ranking.

Who is affected?

This affects anyone who used com.liferay.portal.kernel.util.TermsOfUseContentProviderRegistryUtil to lookup the com.liferay.portal.kernel.util.TermsOfUseContentProvider service.

How should I update my code?

If com.liferay.portal.kernel.util.TermsOfUseContentProvider is used, update the import package name. If there is any usage in portal-web, update com.liferay.portal.kernel.util.TermsOfUseContentProviderRegistryUtil to com.liferay.portal.kernel.term.of.use.TermsOfUseContentProviderUtil. Remove usages of com.liferay.portal.kernel.util.TermsOfUseContentProviderRegistryUtil in modules and use the @Reference annotation to fetch the com.liferay.portal.kernel.term.of.use.TermsOfUseContentProvider service instead.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Removed HibernateConfigurationConverter and Converter

What changed?

The interface com.liferay.portal.kernel.util.Converter and its implementation com.liferay.portal.spring.hibernate.HibernateConfigurationConverter were removed.

Who is affected?

This removes the support of generating customized portlet-hbm.xml files implemented by HibernateConfigurationConverter. Refer to LPS-5363 for more information.

How should I update my code?

You should remove usages of HibernateConfigurationConverter. Make sure the generated portlet-hbm.xml is accurate.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Switched to Use JDK Function and Supplier

What changed?

The Function and Supplier interfaces in package com.liferay.portal.kernel.util were removed. Their usages were replaced with java.util.function.Function and java.util.function.Supplier.

Who is affected?

This affects anyone who implemented the Function and Supplier interfaces in package com.liferay.portal.kernel.util.

How should I update my code?

You should replace usages of com.liferay.portal.kernel.util.Function and com.liferay.portal.kernel.util.Supplier with java.util.function.Function and java.util.function.Supplier, respectively.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Deprecated the com.liferay.portal.service.InvokableService Interface

What changed?

The InvokableService and InvokableLocalService interfaces in package com.liferay.portal.kernel.service were removed.

Who is affected?

This affects anyone who used InvokableService and InvokableLocalService in package com.liferay.portal.kernel.service.

How should I update my code?

You should remove usages of InvokableService and InvokableLocalService. Make sure to use the latest version of Service Builder to generate implementations for services in case there is any compile errors after removal.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Dropped Support of ServiceLoaderCondition

What changed?

The interface ServiceLoaderCondition and its implementation DefaultServiceLoaderCondition in package com.liferay.portal.kernel.util were removed.

Who is affected?

This affects anyone using ServiceLoaderCondition and DefaultServiceLoaderCondition.

How should I update my code?

You should remove usages of ServiceLoaderCondition. Update usages of load methods in com.liferay.portal.kernel.util.ServiceLoader according to the updated method signatures.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Switched to Use JDK Predicate

What changed?

The interface com.liferay.portal.kernel.util.PredicateFilter was removed and replaced with java.util.function.Predicate. As a result, the following implementations were removed:

  • com.liferay.portal.kernel.util.AggregatePredicateFilter

  • com.liferay.portal.kernel.util.PrefixPredicateFilter

  • com.liferay.portal.kernel.portlet.JavaScriptPortletResourcePredicateFilter

  • com.liferay.dynamic.data.mapping.form.values.query.internal.model.DDMFormFieldValuePredicateFilter

The com.liferay.portal.kernel.util.ArrayUtil_IW class was regenerated.

Who is affected?

This affects anyone who used PredicateFilter, AggregatePredicateFilter, PrefixPredicateFilter, JavaScriptPortletResourcePredicateFilter, and DDMFormFieldValuePredicateFilter.

How should I update my code?

You should replace usages of com.liferay.portal.kernel.util.PredicateFilter with java.util.function.Predicate. Additionally, remove usages of AggregatePredicateFilter, PrefixPredicateFilter, JavaScriptPortletResourcePredicateFilter, and DDMFormFieldValuePredicateFilter.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Removed Unsafe Functional Interfaces from the com.liferay.portal.kernel.util Package

What changed?

The com.liferay.portal.osgi.util.test.OSGiServiceUtil class was removed. Also, the following interfaces were removed from the com.liferay.portal.kernel.util package:

  • UnsafeConsumer

  • UnsafeFunction

  • UnsafeRunnable

Who is affected?

This affects anyone using the class/interfaces mentioned above.

How should I update my code?

The com.liferay.portal.osgi.util.test.OSGiServiceUtil class has been deprecated since Liferay Portal 7.1. If usages for this class still exist, replace it with its direct replacement: com.liferay.osgi.util.service.OSGiServiceUtil. Replace usages of UnsafeConsumer, UnsafeFunction and UnsafeRunnable with their corresponding interfaces in package com.liferay.petra.function.

Why was this change made?

This is one of several steps to clean up kernel provider interfaces to reduce the chance of package version lock down.

Deprecated NTLM in Portal Distribution

What changed?

NTLM modules have been moved from the portal-security-sso project to a new project named portal-security-sso-ntlm. This new project is deprecated and available to download from Liferay Marketplace.

Who is affected?

This affects anyone using NTLM as an authentication system.

How should I update my code?

If you want to continue using NTLM as an authentication system, you must download the corresponding modules from Liferay Marketplace. Alternatively, you can migrate to Kerberos (recommended), which requires no changes and is compatible with Liferay Portal 7.0+.

Why was this change made?

This change was made to avoid using an old proprietary solution (NTLM). Kerberos is now recommended, which is a standard protocol and a more secure method of authentication compared to NTLM.

Deprecated OpenID in Portal Distribution

What changed?

OpenID modules have been moved to a new project named portal-security-sso-openid. This new project is deprecated and available to download from Liferay Marketplace.

Who is affected?

This affects anyone using OpenID as an authentication system.

How should I update my code?

If you want to continue using OpenID as an authentication system, you must download the corresponding module from Liferay Marketplace. Alternatively, you should migrate to OpenID Connect, available on Liferay Portal Distribution.

Why was this change made?

This change was made to avoid using a deprecated solution (OpenID). OpenID Connect is now recommended, which is a more secure method of authentication since it runs on top of OAuth.

Deprecated Google SSO in Portal Distribution

What changed?

Google SSO modules have been moved from the portal-security-sso project to a new project named portal-security-sso-google. This new project is deprecated and available to download from Liferay Marketplace.

Who is affected?

This affects anyone using Google SSO as an authentication system.

How should I update my code?

If you want to continue using Google SSO as an authentication system, you must download the corresponding module from Liferay Marketplace. Alternatively, you can use OpenID Connect.

Why was this change made?

This change was made to avoid using an old solution for authentication (Google SSO). OpenID Connect is the recommended specification to use Google implementation for authentication.

Removed Liferay.Loader.addModules from liferay-amd-loader

What changed?

The addModules function was removed from liferay-amd-loader version 4.x and later.

Who is affected?

This affects anyone using liferay-amd-loader directly to define modules.

How should I update my code?

There is no direct replacement for Liferay.Loader.addModules.

One alternative is to create a JS Toolkit project to publish modules: https://github.com/liferay/liferay-frontend-projects/tree/master/maintenance/projects/js-toolkit/docs

Why was this change made?

Performing all module resolutions in the server side boosts speed and network performance.

Updated AlloyEditor v2.0 Includes New Major Version of React

What changed?

AlloyEditor was upgraded to version 2.0.0, which includes a major upgrade from React v15 to v16.

The React.createClass was deprecated in React v15.5.0 (April 2017) and removed in React v16.0.0 (September 2017). All the buttons bundled with AlloyEditor have been updated to use the ES6 class syntax instead of React.createClass.

Who is affected?

This affects anyone who built their own buttons using React.createClass. The createClass function is no longer available, and attempts to access it at runtime will trigger an error.

How should I update my code?

You should update your code in one of two ways:

Why was this change made?

This change was made to use a newer major version of React, which brings performance and compatibility improvements and reduces the bundle size by removing deprecated APIs.

Deprecated the dl.tabs.visible Portal Property

What changed?

The dl.tabs.visible property let users toggle the visibility of a Documents and Media widget’s navigation tabs when placed on a widget page. This configuration option has been removed, so the navigation tab will never appear on widget pages.

Who is affected?

This affects anyone who set the dl.tabs.visible property to true.

How should I update my code?

No code changes are necessary.

Why was this change made?

Documents & Media has been reviewed from a UX perspective, and removing the navigation tabs in widget pages was part of a UI clean up process.

Moved the User Menu out of the Product Menu

What changed?

The User Menu was removed from the Product Menu, and the user menu entries were moved to the new Personal Menu, a dropdown menu triggered by the user avatar.

Who is affected?

This affects anyone who has customized the User Menu section of the Product Menu.

How should I update my code?

If you would like to keep your custom user menu entries and have them available in the Personal Menu, you need to implement the PersonalMenuEntry interface. All panel apps registered with the PanelCategoryKeys.USER, PanelCategoryKeys.USER_MY_ACCOUNT, and PanelCategoryKeys.USER_SIGN_OUT panel category keys should be converted to PersonalMenuEntry.

Why was this change made?

Product navigation has been reviewed from a UX perspective, and removing the User Menu from the Product Menu and splitting the menu to its own provides a better user experience.

Removed Hong Kong and Macau from the List of Countries

What changed?

Hong Kong and Macau have been removed from the list of countries and listed as regions of China as Xianggang (region code: CN-91) and Aomen (region code: CN-92), respectively.

Who is affected?

This affects anyone who used Hong Kong or Macau in their addresses.

How should I update my code?

No code changes are necessary. However, if you have hardcoded the countryId of Hong Kong and Macau in your code, they should be updated to China’s countryId. References to Hong Kong and Macau should be done with their corresponding regionId.

Why was this change made?

After the handover of Hong Kong in 1997 and of Macau in 1999, Hong Kong and Macau are now the special administrative regions of China.

JGroups Was Upgraded From 3.6.16 to 4.1.1

What changed?

JGroups was upgraded from version 3.6.16 to 4.1.1.

Who is affected?

This affects anyone using Cluster Link.

How should I update my code?

The cluster.link.channel.properties.* property in portal.properties no longer accepts a connection string as a value; it now requires a file path to a configuration XML file. Some of the protocol properties from 3.6.16 are removed and no longer parsed by 4.1.1; you should update the protocol properties accordingly.

Why was this change made?

This upgrade was made to fix a security issue.

Liferay AssetEntries_AssetCategories is No Longer Used

What changed?

Previously, Liferay used a mapping table and a corresponding interface for the relationship between AssetEntry and AssetCategory in AssetEntryLocalService and AssetCategoryLocalService. This mapping table and the corresponding interface have been replaced by the table AssetEntryAssetCategoryRel and the service AssetEntryAssetCategoryRelLocalService.

Who is affected?

This affects any content or code that relies on calling the old interfaces for the AssetEntries_AssetCategories relationship, through the AssetEntryLocalService and AssetCategoryLocalService.

How should I update my code?

Use the new methods in AssetEntryAssetCategoryRelLocalService to retrieve the same data as before. The method signatures haven’t changed; they have just been relocated to a different service.

Example

Old way:

List<AssetEntry> entries =
AssetEntryLocalServiceUtil.getAssetCategoryAssetEntries(categoryId);

for (AssetEntry entry: entries) {
  ...
}

New way:

long[] assetEntryPKs =
_assetEntryAssetCategoryRelLocalService.getAssetEntryPrimaryKeys(assetCategoryId);

for (long assetEntryPK: assetEntryPKs) {
  AssetEntry = _assetEntryLocalService.getEntry(assetEntryPK);
  ...
}

...

@Reference
private AssetEntryAssetCategoryRelLocalService _assetEntryAssetCategoryRelLocalService;

@Reference
private AssetEntryLocalService _assetEntryLocalService;

Why was this change made?

This change was made due to changes resulting from LPS-76488, which let developers control the order of a list of assets for a given category.

Auto Tagging Must Be Reconfigured Manually

What changed?

Auto Tagging configurations were renamed and reorganized. There’s no longer an automatic upgrade process, so you must reconfigure Auto Tagging manually.

Who is affected?

This affects DXP 7.2 installations that are upgraded to SP1 and have Auto Tagging configured and enabled.

How should I update my code?

You must reconfigure Auto Tagging through System Settings (please see the official documentation for details). Any code referencing the old configuration interfaces must be updated to use the new ones.

Why was this change made?

This change unifies the previously split configuration interfaces, improving the user experience.

Moved Blogs Image Portal Properties to System Settings

What changed?

Blogs image configuration was moved from portal.properties to System Settings. There’s no automatic upgrade process, so custom Blogs image properties must be reconfigured manually.

Who is affected?

This affects DXP 7.2 installations that are upgraded to SP1 and have custom values for the blogs.image.max.size and blogs.image.extensions properties.

How should I update my code?

If you would like to keep your custom Blogs image property values, you must reconfigure them through the System Settings under Configuration → Blogs → File Uploads. Any code referencing the old properties must be updated to use the new configuration interfaces.

Why was this change made?

This change was made so Blogs image properties can be configured without a restart.

Removed the Cache Bootstrap Feature

What changed?

The cache bootstrap feature has been removed. These properties can no longer be used to enable/configure cache bootstrap:

ehcache.bootstrap.cache.loader.enabled, ehcache.bootstrap.cache.loader.properties.default, ehcache.bootstrap.cache.loader.properties.${specific.cache.name}.

Who is affected?

This affects anyone using the properties listed above.

How should I update my code?

There’s no direct replacement for the removed feature. If you have code that depends on it, you must implement it yourself.

Why was this change made?

This change was made to avoid security issues.

Disabled ContentTransformerListener By Default

What changed?

ContentTransformerListener is now disabled by default.

Who is affected?

This affects Liferay Portal installations that used legacy web content features provided by the ContentTransformerListener, such as embedding web content inside another web content, a legacy edit in place infrastructure, token replacements (@article_group_id@, @articleId;elementName@), etc.

How should I update my code?

There’s no need to update your code. If you still want to use ContentTransformerListener, you can enable it in System Settings.

Why was this change made?

ContentTransformerListener runs a lot of string processes on article elements (calling HtmlUtil.stripComments and HtmlUtil.stripHtml on article fields). It was disabled to improve performance.

Replaced Method in DDMDataProvider

What changed?

The ddmDataProviderContext parameter (of type com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContext) of com.liferay.dynamic.data.mapping.data.provider.DataProvider’s getData method was replaced with ddmDataProviderRequest (of type com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest).

Who is affected?

This affects anyone using the replaced method.

How should I update my code?

Replace the parameter of type com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContext with another one of type com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Removed Constructor in DDMDataProviderRequest

What changed?

The constructor method was removed from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest.

Who is affected?

This affects anyone using the removed constructor.

How should I update my code?

Use com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest.Builder to create a new com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest with all desired parameters instead of the constructor.

Why was this change made?

This change is as part of the Data Provider API Refactoring on LPS-81563.

Removed Methods in DDMDataProviderRequest

What changed?

These methods were removed from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest:

  • getDDMDataProviderContext

  • setDDMDataProviderContext

  • getHttpServletRequest

  • getParameter

  • queryString

Who is affected?

This affects anyone who used the removed methods.

How should I update my code?

Use com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest and com.liferay.dynamic.data.mapping.data.provider.internal.DDMDataProviderInstanceSettingsImpl to get the data provided by com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContext.

Also, add a javax.servlet.http.HttpServletRequest object through the com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest.Builder using the method withParameter and retrieve it using the method getParameterOptional.

Use the existing method getParameterOptional instead of getParameter. Replace the usage of queryString with the method withParameter from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest.Builder to add all necessary parameters.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Replaced Method in DDMDataProviderRequest

What changed?

com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest’s getDDMDataProviderInstanceId method was replaced with getDDMDataProviderId.

Who is affected?

This affects anyone who used the replaced method.

How should I update my code?

Replace the usages of getDDMDataProviderInstanceId with getDDMDataProviderId.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Removed Methods in DDMDataProviderResponse

What changed?

The methods error, of, and getDataMap were removed from the class com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse.

Who is affected?

This affects anyone who used the removed methods.

How should I update my code?

Use these updated methods in your code:

  • Use com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse.Builder’s withStatus method, instead of calling the error method.

  • Replace the of method with the Builder’s withStatus and withOutput methods.

  • Replace getDataMap calls with an output addition using the Builder’s withOutput method, and get it through the method getOutputOptional.

The method withOutput can be invoked as many times you need.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Replaced a Method in DDMDataProviderResponse

What changed?

com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse’s get method was replaced with getOutputOptional.

Who is affected?

This affects anyone who used the replaced method.

How should I update my code?

Use getOutputOptional instead of get.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Replaced an Enum in DDMDataProviderResponse

What changed?

The local enum com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse.Status, from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse, was moved to com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponseStatus. Consequently, The data type of getStatus, from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse, has changed from com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse.Status to com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponseStatus.

Who is affected?

This affects anyone who used the replaced enum.

How should I update my code?

Replace the usages of com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponse.Status with com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponseStatus.

Why was this change made?

This change is part of the Data Provider API Refactoring on LPS-81563.

Deleted DDMDataProviderResponseOutput

What changed?

com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponseOutput was deleted.

Who is affected?

This affects anyone who used the removed class.

How should I update my code?

There’s no direct replacement for the removed class. If you have code that depends on it, you must implement it yourself.

Why was this change made?

The class com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderResponseOutput was deleted without deprecation warning because it became unused after improvements were implemented on Data Provider code in LPS-81563

Removed a Method in DDMDataProviderTracker

What changed?

com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderTracker’s getDDMDataProviderContextContributors method was removed.

Who is affected?

This affects anyone who used the removed method.

How should I update my code?

Use com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest and com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderInstanceSettings instead of getDDMDataProviderContextContributors to get the data you need.

Why was this change made?

All data provided by the com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContext class can be found in the classes com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderRequest and com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderInstanceSettings. The classes com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContext and com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContextContributor are therefore no longer required. Note that com.liferay.dynamic.data.mapping.data.provider.DDMDataProviderContextContributor was removed in Liferay Portal 7.2.

Replaced a Method in DDMFormInstanceRecordLocalService

What changed?

This change was made for com.liferay.dynamic.data.mapping.service.DDMFormInstanceRecordLocalService, com.liferay.dynamic.data.mapping.service.DDMFormInstanceRecordLocalServiceUtil and com.liferay.dynamic.data.mapping.service.DDMFormInstanceRecordLocalServiceWrapper:

The getDDMFormValues method had a single parameter called ddmStorageId (of type long), and now it has two parameters: storageId (replaced ddmStorageId) and ddmForm (of type com.liferay.dynamic.data.mapping.model.DDMForm).

Who is affected?

This affects anyone who used the replaced methods.

How should I update my code?

Pass a new parameter of type com.liferay.dynamic.data.mapping.model.DDMForm in the methods.

Why was this change made?

This change is part of the Storage Adapter API Refactoring on LPS-81564

Removed Methods in DDMStructureService

What changed?

The methods listed below were removed from these classes com.liferay.dynamic.data.mapping.service.DDMStructureService, com.liferay.dynamic.data.mapping.service.DDMStructureServiceUtil, and com.liferay.dynamic.data.mapping.service.DDMStructureServiceWrapper:

  • addStructure (with the parameters long userId, long groupId, long classNameId, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, com.liferay.dynamic.data.mapping.model.DDMForm ddmForm, com.liferay.dynamic.data.mapping.model.DDMFormLayout ddmFormLayout, String storageType, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • addStructure (with the parameters long userId, long groupId, long classNameId, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, String xsd, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • addStructure (with the parameters long userId, long groupId, String parentStructureKey, long classNameId, String structureKey, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, String xsd, String storageType, int type, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • addStructure (with the parameters long groupId, long parentStructureId, long classNameId, String structureKey, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, String xsd, String storageType, int type, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • addStructure (with the parameters long userId, long groupId, String parentStructureKey, long classNameId, String structureKey, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, com.liferay.dynamic.data.mapping.model.DDMForm ddmForm, com.liferay.dynamic.data.mapping.model.DDMFormLayout ddmFormLayout, String storageType, int type, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • updateStructure (with the parameters long groupId, long parentStructureId, long classNameId, String structureKey, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, String definition, com.liferay.portal.kernel.service.ServiceContext serviceContext)

  • updateStructure (with the parameters long structureId, long parentStructureId, Map<Locale, String> nameMap, Map<Locale, String> descriptionMap, String definition, com.liferay.portal.kernel.service.ServiceContext serviceContext)

Who is affected?

This affects anyone who used the removed methods.

How should I update my code?

Replace the removed methods with one of the remaining addStructure and updateStructure methods.

Why was this change made?

These methods were deprecated in Liferay Portal 7.0.

Removed Methods in Dynamic Data Mapping Persistence Classes

What changed?

The methods fetchByPrimaryKeys and getBadColumnNames were removed from these classes:

  • com.liferay.dynamic.data.mapping.service.persistence.DDMContentPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMDataProviderInstancePersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstancePersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceRecordPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceVersionPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStorageLinkPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureLayoutPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructurePersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureVersionPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplatePersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMDataProviderInstanceLinkPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceRecordVersionPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureLinkPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplateLinkPersistence

  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplateVersionPersistence

Who is affected?

This affects anyone who used the removed methods.

How should I update my code?

Replace the removed methods with the corresponding one provided in the base class com.liferay.portal.kernel.service.persistence.impl.BasePersistenceImpl.

Why was this change made?

A custom implementation for fetchByPrimaryKeys is not required since there is a default implementation provided in the base class com.liferay.portal.kernel.service.persistence.impl.BasePersistenceImpl.

getBadColumnNames was automatically removed from the interface (e.g. com.liferay.dynamic.data.mapping.service.persistence.DDMContentPersistence) and kept in the implementation class (e.g. com.liferay.dynamic.data.mapping.service.persistence.impl.DDMContentPersistenceImpl) when the classes were generated by Service Builder.

Removed Methods in Dynamic Data Mapping Util Classes

What changed?

The method getBadColumnNames was removed from these classes:

  • com.liferay.dynamic.data.mapping.service.persistence.DDMContentUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMDataProviderInstanceUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceRecordUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMFormInstanceVersionUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStorageLinkUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureLayoutUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureVersionUtil

  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplateUtil

Who is affected?

This affects anyone who used the removed method.

How should I update my code?

Replace the removed method with the corresponding one provided in the base class com.liferay.portal.kernel.service.persistence.impl.BasePersistenceImpl.

Why was this change made?

getBadColumnNames was automatically removed from the persistence utility (e.g. com.liferay.dynamic.data.mapping.service.persistence.DDMContentUtil) and kept in the persistence implementation (e.g. com.liferay.dynamic.data.mapping.service.persistence.impl.DDMContentPersistenceImpl) when the classes were generated by Service Builder.

Renamed module.framework.properties.felix.fileinstall.* Portal Properties to module.framework.properties.file.install.*

What changed?

Portal properties beginning with module.framework.properties.felix.fileinstall. have been renamed to begin with module.framework.properties.file.install..

Who is affected?

This affects anyone who has the portal properties that start with module.framework.properties.felix.fileinstall..

How should I update my code?

Rename portal properties that start with module.framework.properties.felix.fileinstall. to start with module.framework.properties.file.install..

Why was this change made?

This change reflects Apache Felix Fileinstall inlining. Since Liferay now manages and maintains this functionality, the properties are renamed appropriately.

Replaced the buffered.increment.enabled Portal Property

What changed?

Enabling and disabling view count management using buffered.increment.enabled portal properties has been replaced by using view.count.enabled portal properties.

Enabling and disabling view counts globally is now done using the view.count.enabled portal property.

Disabling view counts for a specific entity is now done, for example, by setting view.count.enabled[SomeEntity]=false.

Who is affected?

This affects anyone who has the buffered.increment.enabled=false portal property setting.

This affects anyone who has disabled view counts for some entity (e.g., SomeEntity) using buffered.increment.enabled[SomeEntity]=false portal property settings.

How should I update my code?

Replace buffered.increment.enabled=false with view.count.enabled=false.

Replace buffered.increment.enabled[SomeEntity]=false, where SomeEntity is an entity you’re disabling view counts for, with view.count.enabled[SomeEntity]=false.

Why was this change made?

This facilitates managing view count behavior.

Removed the module.framework.properties.file.install.optionalImportRefreshScope Portal Property

What changed?

The module.framework.properties.file.install.optionalImportRefreshScope portal property has been removed. File install will now always only check managed bundles when scanning for bundles with optional packages that need to be refreshed.

Who is affected?

This affects anyone who specifies the module.framework.properties.file.install.optionalImportRefreshScope portal property.

How should I update my code?

Remove the module.framework.properties.file.install.optionalImportRefreshScope property. File install cannot be configured to use other behavior.

Why was this change made?

There were very few cases where alternate behavior was desireable. File install is the primary way bundles are installed into Liferay, so all bundles are managed by it by default. Removing the branching logic that supports this feature improves code maintainability and readability.

Make .cfg Fils Use the .cfg Format

What changed?

Prior to this change, .cfg files could use the.cfg or .config format. Now .cfg configuration files must use the .cfg format as defined here.

Who is affected?

This affects anyone who has a .cfg file that is using the .config format.

How should I update my code?

Either rename your .cfg file to .config and make sure it uses the .config format or modify your .cfg file to use the .cfg format (see link above).

Why was this change made?

Apache’s file install implementation allowed .cfg files to use the .config format. When we switched to using our own file install implementation, we decided to have stricter format handling to facilitate maintainability.

Not finding what you're looking for?

Pardon our dust as we revamp and transition our product documentation to this site. If something seems missing, please check Liferay Help Center documentation for Liferay DXP 7.2 and previous versions.

Try Liferay's Help Center