Liferay DXP is getting a lot of attention as of late, with articles popping up detailing how the platform has substantially improved usability and extensibility for developers and end-users…but what about the operational aspect? There’s good news on that front as well; Liferay has made some substantial changes in the platform that will directly improve quality-of-life for Liferay DevOps folks.
1. Liferay Configuration Updates
A major change in Liferay DXP is the method by which configuration is applied and stored in the DXP platform. Historically, there have been two places for Liferay configuration to live; on the filesystem in one of the Liferay properties files, or in XML blobs stored in the database. The interaction between those two configuration sets was not always clear-cut, and there was no “standard” way to verify configuration or migrate it from environment to environment.
With Liferay DXP, this is changing; the old properties files are still in use in a limited capacity, but the old database-storage mechanism using an XML internal configuration representation has been eliminated in favor of a new process, leveraging the standard OSGi framework for modular Java applications. Configuration data is entered into the DXP interface as needed, and the DXP UI provides an export mechanism to allow the user to directly export the configuration set once they’re satisfied with the configuration changes. The exported configuration can then be imported directly into another Liferay DXP environment; this allows configuration to be easily promoted from one DXP environment to another while at the same time preserving an easy-to-use experience for end users to customize the platform.
2. OSGi Shell Features
As anyone who is a Liferay follower will know, Liferay, Inc. has been a vocal supporter of the OSGi initiative and has touted the fact that one of the major evolutionary changes in DXP is that it heavily leverages the OSGi framework to provide modularity and extensibility. While this is primarily a development-oriented change, the inclusion of the Apache Felix OSGi implementation 
into Liferay DXP has some profound effects on operations-oriented work as well. While the inclusion of Felix into the DXP runtime has many benefits, there is one specific feature of particular interest: the addition of the Gogo shell interface. The Gogo shell is Felix’s implementation of RFC 147, which defines a standard command interface for OSGi modules. The full set of capabilities provided by the Gogo shell is beyond the scope of this article; however, examples of what can be done via the shell interface include:
- Viewing and setting module or system properties
- Viewing the current lifecycle state of a module
- Diagnosing a module which is currently in a bad state
- Enabling or disabling a module
This inclusion of an interactive interface to the DXP platform adds a powerful new tool to both deployment and troubleshooting activities for both operations and development teams.
3. Changes to DXP Search
Another exciting change to come to Liferay DXP is a complete reworking of the platform’s search component to vastly improve flexibility and scalability. Liferay Portal version 6.2 and earlier used an in-process Apache Lucene engine to handle all portal search requests, and while this architecture is a tried and true way to include search capabilities into the application, it presented performance and scaling problems, especially in mid-size to large implementations. To remedy this, and to future-proof the DXP platform, Liferay has completely abstracted the search implementation into an OSGi-based application, and the platform now leverages Elasticsearch to handle search indexing and queries out-of-the-box.
Elasticsearch is a full-text search engine based on the Lucene library built on a distributed architecture which provides robust scaling and high-availability functionality through a REST-based interface. Packaging the search function into a discrete component utilizing an enterprise-class open-source engine significantly improves the ability of the DXP search function to operate in large-scale, mission-critical applications, while at the same time bringing major feature improvements for smaller applications leveraging DXP.
It is important to note that DXP also ships with the ability to swap out the default Elasticsearch implementation for an Apache Solr implementation, if needed; Elasticsearch and Solr provide a very similar feature set, and either engine can be used with no degradation in the functionality or performance provided by the DXP search function.
4. Changes to the Operational Runtime
One of the most basic changes made in Liferay DXP is that the platform now ships with Java 8 
as its default target JVM runtime. This is a watershed change, allowing all of the benefits of Java 8 to finally be reliably used in a Liferay environment; in particular, this allows folks on the operations side to standardize on the G1GC collector algorithm for JVM garbage collection. A version of G1GC was available in later releases of Java 7, but it lacked a number of optimization features present in Java 8. The direct impact of using Java 8 and G1GC is lower overhead for the Java process, improved ergonomics for Java garbage collection, reduced pause times, and overall improved performance for the portal process.
5. Updated Build Processes
With the update to DXP, Liferay introduced a new set of build tools to enable faster and more reliable build automation to be put into place. Prior to DXP, builds utilized either the Ant build tool (by default) or the Apache Maven build tool; both of these tools served their purpose well, but have been showing their age in the past couple of years.
With Liferay DXP, the standard build tools are now Gradle (for Liferay/OSGi modules) and Gulp (for Liferay themes). This represents a shift in Liferay’s development tooling which will make it much easier for developers to create consistent, high-quality code for deployment into a Liferay environment with a minimum of boilerplate code authoring. Additionally, this shift mimics a shift in the overall development community; both Gradle and Gulp have seen increased adoption among the Java and JavaScript developer communities (respectively) over the past few years.
Operationally, the shift to Gradle and Gulp will simplify and improve continuous integration and delivery pipelines, and will make it much easier to build consistent processes targeted at build and release automation without requiring extensive customization of the build process or environment.
Additional Changes
A few additional changes which, while important, didn’t make the Top 5 list:
- The default application server used by Liferay DXP is now Apache Tomcat version 8, which represents a significant upgrade from version 7.
- The clustering component in Liferay DXP has been redesigned and, as with many of the other internal features of the platform, has been reimplemented as an OSGi-based module.
All in all, there are noteworthy changes in Liferay DXP 7, and if you are a DevOps engineer, you should certainly dig into them.
If you need assistance with your Liferay DevOps strategy and implementation or just need some advice, do reach out to us.
Additional Reading
You can also continue to explore Liferay DXP (What is a Digital Experience Platform?) by checking out The Top 10 New Features in Liferay DXP 7 and Liferay DXP Audience Targeting 2.0 Overview from a functional perspective or Top 5 New Features in Liferay DXP UI Development and Creating JAX-RS REST Services in Liferay DXP from a development perspective.
If you liked what you read, please share this helpful post with your friends and co-workers on your favorite social media here: