Legacy Knowledge Base
Published Jul. 2, 2025

Changes in MVCActionCommands and portletIds

Written By

Justin Choi

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

This article documents changes to the MVCActionCommand type of commands after Liferay DXP 7.0 Fix Pack 11 is deployed. This change most affects developers building portlets in Liferay IDE tools (e.g. Liferay Developer Studio or Liferay Blade).

Before Fix Pack 11, developers did not have to declare javax.portlet.name; it was not necessary for MVCAction commands but only the Liferay DXP 7.0 generated portletId.

Once Fix Pack 11 was deployed, it was discovered that MVCAction commands no longer worked. The rationale was a change in the portal. Liferay DXP 7.0 generated a name for the portlet that did not match the underscored name defined in the PORTLET_NAME constant in the keys class. Therefore, MVCActionCommands will not be triggered.

If javax.portlet.name is not defined in the MVCPortlet, the result is when actions are invoked from MVCActionCommands (for example, AddRecordMVCActionCommand), the MVCPortlet ends up using the method getPortletName() from GenericPortlet and this name is post processed by the portlet container.

Resolution

After Fix Pack 11, the javax.portlet.name has been added to each portlet classes in Liferay DXP 7.0 by default. See the following template from source:

package ${package}.portlet;

import ${package}.constants.${className}PortletKeys;

import com.liferay.portal.kernel.portlet.bridges.mvc.MVCPortlet;

import javax.portlet.Portlet;

import org.osgi.service.component.annotations.Component;

/**
 * @author ${author}
 */
@Component(
	immediate = true,
	property = {
		"com.liferay.portlet.display-category=category.sample",
		"com.liferay.portlet.instanceable=true",
		"javax.portlet.display-name=${artifactId} Portlet",
		"javax.portlet.init-param.template-path=/",
		"javax.portlet.init-param.view-template=/view.jsp",
		"javax.portlet.name="classNamePortletKeysclassName"javax.portlet.resource-bundle=content.Language",
		"javax.portlet.security-role-ref=power-user,user"
	},
	service = Portlet.class
)
public class ${className}Portlet extends MVCPortlet {
}


Developers using Liferay Blade CLI tools will have to manually add this property to all portlets because this property is not included in the project templates. Once added to any custom portlet, this will resolve the issue of MVCActionCommands not being bound to the portlet. The next release should resolve this issue by including javax.portlet.name in all project templates.

Developers using Liferay Developer Studio will find that this property is already included in the project templates in the latest release. 

Additional Information

Did this article resolve your issue ?

Legacy Knowledge Base