Liferay DXP represents a massive evolutionary change in the basic nature of Liferay’s underlying platform, and as such, it presents a unique set of challenges and issues for organizations looking to migrate their old Liferay Portal environments to the latest and greatest. XTIVIA has compiled a list of items to keep in mind when making the plunge from Liferay 6.x to Liferay DXP.
This entry is the first in a series on migrating to Liferay DXP.
Java 8 is the new normal
One of the biggest underlying shifts made in Liferay DXP is that the version of Java used by the platform is now Java 8; Java 8 was supported in later versions of Liferay Portal 6.2, but it was never the default JVM version. Java 8 is quite mature at this point, and brings a multitude of new features that improve the quality of life of Java developers significantly, while at the same time improving both overall performance and maintainability. While applications written for Java 7 can be run on Java 8 (in most cases), it is recommended to budget time into your migration plan to allow for each of your applications to be ported and validated using Java 8.
An additional consideration is that Java 8 provides improved support for the G1GC garbage collection algorithm; anecdotally, we have seen moderate improvements in JVM performance when using the G1GC algorithm over the concurrent-mark-sweep (CMS) algorithm. Using this GC algorithm is entirely optional, but it’s certainly worth testing as a part of a migration plan.
Liferay now requires an external search server
This will probably be one of the more controversial issues that most organizations experience when upgrading to Liferay DXP; Liferay has changed the underlying search engine present in the DXP application to be Elasticsearch. This was done for a number of very good reasons; the search function in the platform has become more and more important over time, and it was necessary to ditch the aging Lucene implementation in favor of a more scalable option. However, this does mean that every new Liferay DXP environment will need to provision separate servers for running the Elasticsearch engine; these servers need to be separate from the Liferay DXP servers themselves! Liferay’s official recommendation is that Elasticsearch servers be provisioned with a minimum of 8 CPU cores and 16GB of memory; 64GB of memory is preferred.
Additionally, if you are migrating a production-class environment, it would be wise to budget additional time and resources to set up a fully-redundant Elasticsearch cluster. An Elasticsearch cluster provides seamless redundancy for search requests and resiliency for the search indexes themselves; using only a single Elasticsearch instance would create a critical single point of failure in your DXP environment.
The default location for deployed apps has changed
This change will mainly impact organizations which have automated processes built around the structure of the application server being used (i.e. using the WebSphere Deployment Manager to deploy applications into a cluster, using Tomcat clustering, configuring session replication on a per-app basis). The Liferay DXP deployment process no longer deploys applications into its target application server’s application deployment directory; instead, it deploys applications to a separate osgi directory located in the Liferay home directory. This directory is used by DXP to store and deploy applications and modules within the OSGi framework container. The impact of this is manifold; application server “clustered” distribution of applications will no longer function, and the applications themselves will now run as OSGi modules within the liferay application, rather than running as baseline web applications within the application server.
For most environments, this change will be transparent; however, it is something to keep in mind when planning out your DXP deployment pipeline or troubleshooting classloader or namespace issues during migration.
Configuration has changed significantly
Historically, there were two common places to store configuration data in Liferay Portal: in the portal-ext.properties file, and in the PortalPreferences_ database table (set via the administration UI). In Liferay DXP, this has changed slightly due to the shift to OSGi modules. The PortalPreferences_ table has been removed entirely, and has been replaced by a modular OSGi-based configuration framework. The portal-ext.properties file is still present, but a number of available configuration settings have been moved to the new configuration framework (a detailed list of the configuration items which are no longer available will be covered in a subsequent posting).
The practical impact of this is twofold; first, any migration project will need to budget time to review and update configuration settings in each environment to match the new configuration processes. Second, any configuration management process in place for promotion of configuration data from environment to environment will need to be updated to use the new OSGi configuration framework. The new framework actually makes it slightly easier to manage configuration promotion, but it is significantly different from the old Liferay Portal process; details on how to build a configuration pipeline for DXP will follow in another post.
Summary
There are a number of significant changes that need to be taken into account when migrating a Liferay Portal 6.x environment over to Liferay DXP; careful attention to detail and planning can help make it as smooth a transition as possible.
If you need assistance with Liferay DXP migration planning and execution, or just want more detail on best practices to use when moving to a DXP environment, please reach out to us.