There are several different ways to customize JSPs in portlets and the core. Liferay DXP’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.
Here are API-based approaches to overriding JSPs in Liferay DXP:
|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.|
It’s strongly recommended to customize JSPs using Liferay DXP’s API, as the previous section describes. Since overriding a JSP using an OSGi fragment or a Custom JSP Bag is 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. These approaches should only be used as a last resort.
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 DXP’s API:
|OSGi fragment||Completely overrides a module’s JSP using an OSGi fragment||Changes to the original JSP or module can cause runtime errors.|
|Custom JSP bag||Completely override a Liferay DXP core JSP or one of its corresponding ||For Liferay DXP 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!