Deploying a Spring MVC Portlet

Developers creating portlets for Liferay DXP can usually deploy their portlet as Java EE-style Web Application ARchive (WAR) artifacts or as Java ARchive (JAR) OSGi bundle artifacts. Spring MVC portlet developers don’t have that flexibility. Spring MVC portlets must be packaged as WAR artifacts because the Spring MVC framework is designed for Java EE. Therefore, it expects a WAR layout and requires Java EE resources such as the WEB-INF/web.xml descriptor.

Because Liferay supports the OSGi WAB (Web Application Bundler) standard for deployment, you can deploy your WAR and it runs as expected in the OSGi runtime. Here are the high points on why that works in Liferay:

• The Liferay auto-deploy process runs, adding the PortletServlet and PlugincontextListener configurations to the WEB-INF/web.xml file.

• The Liferay WAB Generator automatically creates an OSGi-ready META-INF/MANIFEST.MF file. If you want to affect the content of the manifest file, you can place bnd directives and OSGi headers directly into a WEB-INF/liferay-plugin-package.properties file for the WAB.

Import class packages your portlet’s descriptor files reference by adding the packages to an Import-Package header in your liferay-plugin-package.properties file.

Here’s an example Import-Package header:

Import-Package:\
    org.springframework.beans.factory.xml,\
    org.springframework.context.config,\
    org.springframework.security.config,\
    org.springframework.web.servlet.config

The auto-deploy process and Liferay’s WAB generator convert your project to a Liferay-ready WAB. The WAB generator detects your class’s import statements and adds all external packages to the WAB’s Import-Package header. The generator merges packages from your plugin’s liferay-plugin-package.properties into the header also.

If you depend on a package from Java’s rt.jar other than a java.* package, override portal property org.osgi.framework.bootdelegation and add it to the property’s list. Go here for details.

Note: Spring MVC portlets whose embedded JARs contain properties files (e.g., spring.handlers, spring.schemas, spring.tooling) might be affected by issue LPS-75212. The last JAR that has properties files is the only JAR whose properties are added to the resulting WAB’s classpath. Properties in other JARs aren’t added.

For example, suppose that a portlet has several JARs containing these properties files:

• WEB-INF/src/META-INF/spring.handlers
• WEB-INF/src/META-INF/spring.schemas
• WEB-INF/src/META-INF/spring.tooling

The properties from the last JAR processed are the only ones added to the classpath. The properties files must be on the classpath in order for the module to use them.

To add all the properties files to the classpath, you can combine them into one of each type (e.g., one spring.handlers, one spring.schemas, and one spring.tooling) and add them to WEB-INF/src.

Here’s a shell script that combines these files:

cat /dev/null > docroot/WEB-INF/src/META-INF/spring.handlers
cat /dev/null > docroot/WEB-INF/src/META-INF/spring.schemas
cat /dev/null > docroot/WEB-INF/src/META-INF/spring.tooling
for jar in $(find docroot/WEB-INF/lib/ -name '*.jar'); do
for file in $(unzip -l $jar | grep -F META-INF/spring. | awk '
{ print $4 }
'); do
if [ "META-INF/spring.tld" != "$file" ]; then
unzip -p $jar $file >> docroot/WEB-INF/src/$file
echo >> docroot/WEB-INF/src/$file
fi
done
done

You can modify and use the shell script to add your JAR’s properties files to the classpath.

Note: If you want to use a Spring Framework version different from the version Liferay provides, you must name your Spring Framework JARs differently from the ones portal property module.framework.web.generator.excluded.paths excludes. If you don’t rename your Spring Framework JARs, the WAB generator assumes you’re using Liferay’s Spring Framework JARs and excludes yours from the generated WAB. Understanding Excluded JARs explains how to detect Liferay DXP’s Spring Framework version.

Once you’ve packaged your Spring MVC portlet as a WAR, you can deploy it by copying it to [LIFERAY_HOME]/deploy.

Congratulations on deploying your Spring MVC portlet!