Liferay: Welcome to the Rabbit Hole…

Sergey Vasilenko
Java Developer at Rozdoum

IT doesn’t stand still and for a developer who wants to create a web application, there’s a wide variety of frameworks to use.

Foreword

Some of them allow the creation of application as a house with blocks (bricks) – spring, hibernate, guice etc. And it’s up to you to compose a house using those. It’ll require a significant amount of knowledge from the maker but they’re highly customizable (most of the time).

Others (grails, play etc) provide you with the house built using these blocks (in most cases). Empty one – no furniture, no rooms. But house nonetheless. You’ll require some knowledge to divide empty space with walls and make some rooms for yourself, but the carcass is there.

And there’s a third category – inhabited houses which allow you to lease a room. A well-furnished room neighboring with a nasty old hag – the hostess. And don’t you dare move that vase from its sweet spot under your feet! And close that damn window, I’m already sneezing and I don’t care that we’re in different rooms!  Well, you got the idea… One of the bright representatives of this category is Liferay. Let me show you the room and hopefully, after this short tour, you’ll see for yourself if the rent is worth it or not.

Liferay Overview

Welcome to the rabbit hole…

As you’ve probably understood from the foreword Liferay is a web platform coming with a number of ready-to-use applications some of which might suit developer’s needs. There’s also a possibility to write your own applications (portlets) which will be integrated into Liferay and will use vast majority of platform’s capabilities (security, service layer, i18n etc). Apart from that Liferay’s look & feel is easily customizable (given you’re good with HTML markup and CSS. Liferay comes in 2 editions: Community Edition being free one and Enterprise Edition offering additional services.

Let us take a look (maybe more than one) onto positive and negative aspects of Liferay, shall we?

The Good

• It uses Java!

Now seriously:

• Liferay comes with spring, struts, hibernate, velocity and other stuff under its hood. Everything’s configured to work out-of-the-box. And you can use majority of these features in your portlets’ lifecycle.
• Initial setup and deployment is pretty simple thanks to the bundled tomcat and configured HSQL.
• Out of the box, Liferay’s plugin SDK is configured to work with ant, but if you don’t like it you can use maven as a dependency resolution/build/deploy tool (there’s a healthy number of archetypes for Liferay artifacts – themes, portlets, layouts etc). Unfortunately, there’s no native gradle solution.
• Pretty robust service builder. Plugin SDK introduces its own DSL language for building service layer. All you need to do is describe your model in XML file following a number of easy rules, invoke certain ant target/maven plugin and you’ll get a bunch of java class which would satisfy your needs – beans, persistence layer, local and remote services. You can enrich these generated classes with your own functionality – Liferay will preserve it.
• A possibility to invoke secure API without need to manually pass any authentication tokens using remote services.
• Configurable Facebook SSO out-of-the-box.
• Liferay itself updates database structure after model has been changed.
• Possibility for clusterization.
• Bundled Quartz allows you to create periodical jobs without much effort.

Not Good, but keep in mind 

• As a whole Liferay feels like one big CMS (with blogs, wiki, user portal etc) which can be enhanced using custom portlets. If you’re planning to use these capabilities – good, otherwise they’re becoming a dead weight.
• Facebook integration does not take FB accounts created using a phone number instead of email address. There are workarounds but the lack of in-depth documentation makes things look grim.
• Documentation. If you’re planning to write portlets which will be using basic functionality (using services for CRUD, creating hooks) – there’s a high chance you’ll find the solution described here, but if you dig a bit deeper you’ll most likely face complications (take Social Equity for example – functionality which is part of Liferay since v.6.0. If you’re planning to use it for Liferay entities – you shouldn’t face any problems, but if instead, you’d like to integrate with your assets – the documentation feels lacking).
• Liferay developers promote their own IDE based on eclipse. If you’re using something else (NetBeans, IntelliJ) things will become more complicated. There are guides on how to make them friends with each other but they’re outdated. Maven eases this pain but you’ll most likely still need Liferay-portal sources in order to debug Liferay core.
• Maven integration. Don’t take me wrong – it’s great that you can use maven in your development, but Liferay-maven-plugin lacks documentation about essential parts such as its configuration options. Sure, artifact’s .pom file generated from archetype provides all necessary configuration lines for you but what if you’d like to know what exactly does “build-CSS” goal do? You’d have to sift through lots of irrelevant/outdated info that search engines give you. What would be better is having a page somewhere on the internet where all goals, configuration options etc. are listed. Like this one, for example.
• As awesome as it is service builder still has its flaws and restrictions:
  • sometimes hiccups occur if you’ve used wildcard import in one of your local services (certain IDEs do that automatically on optimizing imports (if you didn’t tweak IDEs optimization config)).
  • Finders for a range of fields don’t work – say you have a model with field createDate and you’d like to generate service method which should return all models for the specified date range – you can’t. There are workarounds, however – Dynamic Queries and Custom Queries.
• It’s hard to change Liferay core functionality. Sure you have the means – ext plugin and hooks, but it’s hard to find official documentation on the matter (unless you’ve got a paid version of Liferay) so forums and blogs are your best bets on finding pieces of info.
• Deployment of ext plugin to remote server is complicated:
  • If it’s your first deployment to the given server – everything’s like a piece of cake. All you need to do is put the plugin’s .war file into deployment directory and Liferay will do the rest for you.
  • For each subsequent deployment, you need to manually update pieces of Liferay installation using .war file (out of the box you can redeploy ext plugin only to your local instance).
• There’s no convenient way to create friendly URLs for your portlets. Your options are limited to changing URL rewrite rules of the whole portal or to putting your Liferay installation behind apache2 and set rewriting rules of the latter.

Conclusion

Liferay provides its ecosystem for us to inhabit with our own applications. And as with any ecosystem, it sets a niche for the foreigners restricting them in many ways but providing them with the house where they can settle, protection (spring security), tools necessary for survival (service layer, taglibs etc).

If you’re ok with these restrictions and are going to use the majority of functions Liferay provides out of the box – I’d say “give it a shot”. Be ready for the problems with the documentation, though. And keep in mind that flaws listed in “The Bad” section have workarounds.

If you want more control over the process – there are far better alternatives depending on how much control do you want (see “Foreword” section).