PortletMVC4Spring Configuration Files
A PortletMVC4Spring application has these descriptors, Spring contexts, and properties files in its WEB-INF
folder:
web.xml
→ Web application descriptorportlet.xml
→ Portlet application descriptorliferay-portlet.xml
→ Liferay-specific portlet descriptorliferay-display.xml
→ Liferay-specific display descriptorspring-context/portlet-application-context.xml
→ Portlet application contextspring-context/portlet/[portlet]-context.xml
→ Portlet contextliferay-plugin-package.properties
→ Packaging descriptor
Examples of each file are provided and portlet-specific content is highlighted.
web.xml
The servlet container processes the web.xml
. This file specifies the servlet that render’s the portlet and the portlet application’s context, servlet, filters, listeners, and more. Here’s an example web.xml
:
The <context-param/>
element gives the path to the portlet application context (discussed later):
The <servlet/>
and <servlet-mapping/>
elements set the servlet and the internal location for its views.
The ViewRendererServlet
. converts portlet requests into servlet requests and enables the view to be rendered using the Spring Web MVC infrastructure and the infrastructure’s renderers for JSP, Thymeleaf, Velocity, and more.
The filter and filter mappings are set to forward and include servlet views as necessary.
A listener is configured for processing the application’s contexts.
Liferay’s project archetypes generate all this boilerplate code.
portlet.xml
The portlet.xml
file describes the portlet application to the portlet container. Here’s an example:
This application has one portlet named portlet1
.
The <portlet-name/>
is internal and the <display-name/>
is shown to users. <portlet-class/>
specifies the portlet’s Java class.
Important: All PortletMVC4Spring portlets must specify <portlet-class>com.liferay.portletmvc4spring.DispatcherPortlet</portlet-class>
.
The <supports/>
element must declare the mime type that the portlet templates use.
The <resource-bundle/>
sets the path to the portlet’s localized Java message properties. For example, the element refers to properties at content/portlet1.properties
:
The <portlet-info/>
element lists the portlet’s titles and reserved keyword.
The <security-role-ref/>
elements declare default user roles the portlet accounts for.
Lastly, the <filter/>
named SpringSecurityPortletFilter
prevents Cross-Site Request Forgery (CSRF).
The portlet XSD
defines the portlet.xml
. The Liferay-specific portlet descriptor is next.
liferay-portlet.xml
The liferay-portlet.xml
file applies Liferay-specific settings that provide more developer features. Here’s an example:
This <portlet/>
element associates an icon with the portlet and indicates that name-spaced parameters aren’t required.
The <role-mapper/>
elements associate the portlet with default Liferay DXP user roles.
The liferay-portlet-app-[version].dtd
file defines the liferay-portlet.xml
file.
liferay-display.xml
The liferay-display.xml
applies display characteristics to the portlet. For example, this descriptor associates the portlet with a Widget category in Liferay DXP’s Add Widget menu.
See liferay-display-[version].dtd
file for details.
It’s time to look at the application contexts.
Portlet Application Context
This context applies to all of the application’s portlets. This is where you specify view resolvers, resource bundles, security beans, proxies, and more. Here’s an example:
The view resolver bean above handles JSPX view templates. To resolve Thymeleaf view templates, for example, you could specify these beans:
The context’s springSecurityPortletConfigurer
bean facilitates using Spring Security:
You can also designate contexts for each portlet in the application.
Portlet Contexts
Beans specific to a portlet, go in the portlet’s context. Since annotations are the easiest way to develop PortletMVC4Spring portlets, you should specify MVC annotation scanning in the portlet context:
The portlet context naming convention is [portlet-name]-context.xml
. To associate your portlet with its own context, edit your application’s portlet.xml
file and add an <init-param/>
element that maps the <portlet/>
element to the portlet’s context:
What’s left is to describe your application package.
liferay-plugin-package.properties
This file specifies the application’s name, version, Java package imports/exports, and OSGi metadata. Here’s an example package properties file:
It uses this OSGi metadata header to import required Java packages:
On deploying the portlet application WAR file, the WAB Generator adds the specified OSGi metadata to the resulting web application bundle (WAB) that’s deployed to Liferay’s runtime framework.
The liferay-plugin-package-[version].dtd
file describes the liferay-plugin-package.properties
file.