Liferay 6 vs Jahia 6.5

Liferay and Jahia are excellent solutions for the implementation of Enterprise Web Applications. Here I am focusing the comparative analysis on the following:

• Content Integration Model and 
• Extensibility Model. 

Content Integration Model

• Integration with external services,
• Integration with different DBMS, 
• Consuming external RSS feeds 
• Communication between components.

Architecture & Web Services Integration

Liferay and Jahia are products with a robust architecture that use the latest Java framework to accomplish their goals. Both solution use the Apache Jackrabbit for content storage and can also be configured to access other types of repositories via the JCR API. 

One architecture difference is that Liferay has an architecture based on SOAP and Jahia uses the REST API, but using both ways we can integrate both products to external services.

Supported Databases

Both products support almost all the DBMS, but there is a big difference on the community versions. 

Liferay EE and CE support Microsoft SQL Server and Oracle, but Jahia only supports those DBMS in the Enterprise version.

RSS Integration

The rendering of RSS feeds is supported on both products and both have ready to go portlets/modules for rendering. Liferay has the RSS Portlet and Jahia has the 'Display External RSS' module. Jahia’s 'Display External RSS' uses the RSS URL and number of entries, in the same way Liferay’s RSS Portlet uses them.

Communication between components

Communication to different databases is supported by both products. Liferay and Jahia can connect to different databases adding different sources in the context.xml file. The sharing of information between components in Liferay can be done via the Inter-Portlets Communication API. The sharing of information between modules in Jahia seems to be more integrated, because Jahia modules can communicate each other by simply using the context of a session.

Extensibility Model

Both products present similar ways to add/extend functionality, but there are some following differences:

Add/Extend Portable Functionality

Portlets are supported by and can be used in both products. The development effort in both cases is almost the same, but both systems provide to developers different tools for development. Liferay has the Plugins SDK tool in order to create portlet projects. In a similar way, Jahia has a maven archetype that can be used for this same purpose.

Jahia also can be extended via modules that are considered plugins. The advantage of modules over portlets is that they don’t need a Portal Sever and they are integrated directly into Jahia’s core gaining direct access to Jahia features. This means that developers using modules, apart from extending Jahia functionality, can add functionality to the default Jahia modules. Liferay doesn’t have this type of extensibility so I consider it an advantage of Jahia over Liferay.

Extend/Modify Core

Liferay has a very interesting method to overwrite files, beans, Struts Actions and properties in the core. It uses Hooks and Ext Plugins. This feature is based on the configuration of xml files that contain information about which files are going to be replaced. 
This feature does not exist on Jahia as those modules just can add new files but cannot replace core files.

I think that both products are excellent solutions and can work for any type of Enterprise Web Application. There are some differences, but in the end, both products can accomplish the same objectives:

• Maintainability
• Usability 
• Portability 

Also, the development time, effort and skills are similar because each product offers powerful tools, like Liferay SDK and Jahia Maven archetype to generate extensibility projects

Calling Methods | Internal Liferay API

Liferay has a robust service-layer API for developers to use. However, sometimes there are cases when you need to use methods in the internal Liferay API. You can't use the internal API directly, but you can invoke it indirectly with the PortalClassInvoker class.


here is a example:

Stack<JournalArticle> recentArticleStack = (Stack<JournalArticle>)
PortalClassInvoker.invoke( false, "com.liferay.portlet.journal.util.JournalUtil", "getRecentArticles", new String[] {"javax.portlet.PortletRequest"},
actionRequest);

Here is the method signature for PortalClassInvoker.invoke( ) :

invoke(boolean newInstance, String className, String methodName, 

    String[] parameterTypeNames, Object... arguments) 

For more details visit : 

http://docs.liferay.com/portal/6.0/javadocs/com/liferay/portal/kernel/util/PortalClassInvoker.html

Note:

Use of "PortalClassInvoker" class should be the exception rather than the rule. Should always attempt to find a solution using the Liferay Service-Level API before resorting to the use of PortalClassInvoker.

Why is Liferay Portal is best choice in my view

1. Liferay has Rich out-of-the-box functionality in most area like Core Portal, CMS, Collaboration, Social, Mobile and Security etc. For more details you can check out http://www.liferay.com/products/liferay-portal/features/portal.
2. Liferay support Hooks/Extension/Plugins/Custom Development Environment to deliver requisite functionality within limited budget.
3. Liferay’s Open Source nature and architecture help avoid lock-in to a single proprietary vendor based portal product.
4. Liferay has the lowest Total Cost of Ownership compared to its competitors starting with its licensing and getting it up and running through development costs, operational costs, and training and support cost from the perspective of Infrastructure, Development teams, Administration.
5. Liferay introduce new capabilities whether it be AJAX,Mobile, Social and Friendly URLs
6. Liferay is lightweight in its nature. It is quickly to get it up and running, as well as easier to develop and manage. So Liferay improved the Agility in Business execution.
7. Liferay is a mature Enterprise Open Source Portal Product. Liferay community provide 24x7x365 support with 1 hour response time SLA ( in case of Platinum Support Plan). Support includes access to all service packs, hot fixes, notifications of security alerts, phone and web based support.
8. Liferay’ provide Hook and Extension Plugin Model allows to tailor Liferay behavior  as per the business needs without rewriting functionality from scratch.
9. Liferay offers the flexibility to make a full choice of  Application Servers,  Databases, and Operating Systems Platform to run on.
10. Liferay provide a solution that works today and is flexible enough to drive future strategic growth. It is more flexible than SharePoint.

New Features of Liferay 6.1

1) Greatly Improved Document Library with a redesigned UI.

• It allows to integrate several existing content repositories (CMIS, Sharepoint, Documentum, Alfresco).
• Image Gallery and Document Library will be unified

2) Support for Staging

• modify several versions of your portal at the same time
• create a special christmas version without having to change all your sites.

3) Web Content title and description finally be translatable

4) Simplified publishing of contents

• Let end-users publish content without having to fight with asset publisher properties.
• Link Web Content Links to configurable pages

5) Taxonomy Enhacements

• internationalization for vocabularies and categories
• mandatory vocabularies
• multi valued categorization

6) Custom Entities
This seems very interesting: A possibility to create a Liferay Service with Entities and GUIs simply by using a portlet. Sounds like taking the Liferay Service approach to a whole new level by also generating GUIs and allowing Users to do this within Liferay - not within Eclipse. 

7) Workflow Aware Forms
Very interesting approach to create work-flows and the GUIs / Forms that fit into the workflow as single steps. Should be possible to define business processes without development. Lets hope that all this data is exportable somehow...

8) Implementation of OpenSocial 1.1 

9) Improved Social Features

Liferay 6.1 introduce a Contact Center that contain all Friends, FriendsRequests, Followers etc. Very good feature that incorporate all the portlets that you have to find for yourself, create a page, configure everything etc etc. It also contain "short status updates"  - looks like a twitter clone to me.

10) Redesigned Calendar portlet
Finally - the calendar portlet completely rewritten, looks a little like the Google Calendar. Possibility to add resources like conference rooms and view the availability of these resources. This will maybe help to save costs for firms.

11) Improved Message Boards

12) Improved Blogs

• Attachments
• Auto tagging
• sharing via Facebook and twitter

13) Improved Chat

The Chat Portlet rewritten and contain features such as message broadcasts to a group of users, offline messaging and a chat history with pruning

14) Mobile themes
Mobile themes for iPhone, iPad and Android will be available out of the box. This is one of the main requested features of my customers.

15) Suport for SAML 2.0

16) Improved documentation

17) Improved Liferay IDE and Liferay Developer Studio

• Create JSF 2.0 Portlets
• Visual UI builder with AlloyUI
• Workflow designer

How to configure "Dockbar" based on "Roles"?

#if ($permissionChecker.isOmniadmin())
#dockbar()
#end

This  below code will check if logged in user is Admin or Content Editor or Content Admin, then show dockbar, for rest of the user, hide the dock bar.

#if ( $is_signed_in )    
   #set ($rService = $serviceLocator.findService("com.liferay.portal.service.RoleService"))
   #set ($usrRoles = $rService.getUserRoles( $user_id ))
   #foreach( $usrRole in $usrRoles )
      #if ( $usrRole.getName() == "Administrator" || $usrRole.getName() == "Content-Admin" || $usrRole.getName() == "Content-Editor")
         #dockbar()
      #end
   #end
#end


#if ( $is_signed_in )
   #if ( $user.getScreenName() == "superadmin")
      #dockbar()
   #end
#end

LogOut:

#if ($show_sign_out)
   <a title="Sign Out" href="$sign_out_url" style="float:right;">$sign_out_text</a>
#end