The recommendation for the @Reference annotation in this tutorial is flawed:
Per this Liferay extension scheme, a typical MVC command override class needs to declare two things:
1) What command and portlets it is trying to override: this is achieve by the @Component annotation and these two properties:
- "javax.portlet.name" (multiple values, one per portlet name)
- "mvc.command.name" (single value)
2) The option to call the original Liferay MVC command: this is achieved by the @Reference annotation. This tutorial uses the two properties identical to 1).
With that, CustomLoginMVCActionCommand now has the identical property set used to find the original 'mvcActionCommand'. When Liferay OSGi initializes, it loads modules in LIFERAY_HOME/osgi/modules first, making CustomLoginMVCActionCommand the first component in the module registry, ahead of the Liferay MVC command it overrides. Then OSGi will match CustomLoginMVCActionCommand itself while searching the registry for that set of properties to satisfy the @Reference annotation.
That leads to these errors during Liferay startup and the override component inoperable:
The @Reference annotation must use a distinctively different property to find the original MVC command. While debugging this, I found out that every component has property component.name set to its implementation class name. Using that property, both of these versions work:
The use of 'component.name' should be promoted as the recommended way for the @Reference annotation of an overriding MVC command to find the original Liferay MVC command.