There are several different ways to customize JSPs in portlets and the core. Liferay Portal’s API provides the safest ways to customize them. If you customize a JSP by other means, new versions of the JSP can render your customization invalid and leave you with runtime errors. It’s highly recommended to use one of the API-based ways.
Using Liferay Portal’s API to Override a JSP
Here are API-based approaches to overriding JSPs in Liferay Portal:
|Dynamic includes||Adds content at dynamic include tags.||Limited to JSPs that have |
|Portlet filters||Modifies portlet requests and/or responses to simulate a JSP customization.||Although this approach doesn’t directly customize a JSP, it achieves the effect of a JSP customization.|
Overriding a JSP Without Using Portal’s API
It’s strongly recommended to customize JSPs using Liferay Portal’s API, as the previous section describes. As of Liferay 7.0, overriding a JSP using an OSGi fragment or a Custom JSP Bag are both deprecated. Since these approaches are not based on APIs there’s no way to guarantee that they’ll fail gracefully. Instead, if your customization is buggy (because of your code or because of a change in Liferay), you are most likely to find out at runtime, where functionality breaks and nasty log errors greet you.
If you’re maintaining a JSP customization that uses one of these approaches, you should know how they work. This section describes them and links to their tutorials.
Here are ways to customize JSPs without using Liferay Portal’s API:
|OSGi fragment (deprecated as of Liferay 7.0)||Completely overrides a module’s JSP using an OSGi fragment||Changes to the original JSP or module can cause runtime errors.|
|Custom JSP bag (deprecated as of Liferay 7.0)||Completely override a Liferay Portal core JSP or one of its corresponding ||For Liferay Portal core JSPs only. Changes to the original JSP or module can cause runtime errors.|
All the JSP customization approaches are available to you. It’s time to customize some JSPs!