I’m looking to build a niche social networking site and my preferred language is Java. After a lot of research, it seems to have boiled down to Alfresco Surf & Share or Liferay Collaboration.

In terms of features, Liferay is my preferred choice. The trouble is the portal bit. My research tells me partly because it carries all the JSR 168 plumbing, Liferay isn’t that straightforward to develop against and is very demanding in terms of server resources - a big concern for someone like me that is going to rely on a public hosting company.

I therefore agree that Liferay is far from just another portal but I wonder if the problem is that it is a portal.

I’d be interested to hear what you think, as I genuinely would like to use Liferay for my site.

Hello Richard,

Thanks for the response. At Rivet Logic we work with both Alfresco Share (built on the Alfresco Surf platform) and with Liferay. They are both excellent platforms.

The JSR-168 specification offered a very basic lifecycle API and a set of standard deployment descriptors that did not do a whole lot to enable application development but rather focused on allowing a container to detect, deploy, and present the application. There is value here but it doesn’t become fully apparent unless you are working with applications (portlets) developed using a heterogeneous set of frameworks (JSP, Struts, Spring MVC and so on.) More on this later.

JSR-268 is pretty exciting because it provides actual infrastructure for allowing applications to communicate with each other without the need to roll-your-own solution. At the most basic level, portals are about providing the infrastructure for aggregation of behavior, authorization, authentication, identity and so on. Some would argue that with the introduction of Web 2.0 style mash-ups; functionality traditionally provided by portals is moving to the browser. I think this is only true to a point. Simplicity is certainly a virtue and when it comes to managing an infrastructure you want to be as lean as your needs will allow. If you don’t require much framework and infrastructure; don’t use it. Further, portal is not the only solution for providing rich application aggregation. However, it becomes more and more relevant when components are of heterogeneous makeup.

Developing a JSR-268 portlet requires some know-how but the basics are fairly simple. If the target developers are not Java developers than developing a portlet can seem somewhat challenging. However, Liferay has taken steps to make sure that its a platform supports many types of development (not just pure Java.) For example:

http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/How+to+create+a+simple+php+portlet

In this example no knowledge of portlets or portals is required. You Simply create a set of PHP files and assets, zip them up and use the administration console to install them. No jar management, not build scripts. Just simple. familiar. and fast development. Herein lies the power of the industry standards. You are able to use a wide range of programming language and development tools. If you are comfortable with Java, JSF, Spring MVC or Struts you have a way forward> If you are more comfortable with JQuery and JSP again, you have a way forward. On the other hand, scripting languages are your thing; you have options like PHP, Jython and so forth. In fact each application could potentially be developed in a different language and/or framework yet they can still leverage the underlying capabilities of Liferay’s JSR-286 specification to communicate with one another and to form a coherent composite application.

To address your concern related to server resources: Liferay is a larger application. It requires a 2-3 Ghtz machine with no less than 2 Gigs of RAM. The portal aspects of Liferay are not driving the resource requirements: the feature-set and the implementation are. If you are getting good use (read: a wide range of use) of the feature-set than you are making good use of the consumed resources. There are deployment and tuning scenarios available to Liferay deployments. Tuning is something that is fairly dependent on the requirements and the operational aspects of the deployment.

Alfresco Share and Liferay do overlap in a number of ways, but they are quite different in other respects. Options are good. We find that the best choice depends on the specifics of the requirements, the operational environment and the technical and business teams that will be using the system.

Russ

Thanks for the comprehensive response.

I’m with you when you say “the best choice depends on the specifics of the requirements, the operational environment and the technical and business teams that will be using the system” and I guess that is the crux of your original post - if your requirements dictate the use of a portal, then Liferay is a great choice because you get the portal and a lot more.

For me, considering the three factors, I’ve decided I’m better to opt for a lightweight PHP-based CMS such as SilverStripe (www.silverstripe.org).

Richard

While you’re at it, take a look at Modx .. http://www.modxcms.com. It’s similar to Silverstripe (PHP-based and open-source). Very nice

Hi Russ, your answer is quite extensive, but it does not go to the core of the question. What is being contrasted is Alfresco Surf as a web development framework and Liferay as a portal engine. Alfresco Surf is a portal like framework, but certainly not JSR 168 compliant. Also, I do not really like the architecture of Alfresco Surf. In a two tier configuration it relies on remoting services which are impractical (EJB1 model). So, my vote is behind Liferay.

Sergey,

You are right SURF is not a JSR-168/268 compliant portal. If you need the kind of plugability of application frameworks that the standard provides — then you need a portal. That is to say, if you want to run a Struts application next to a Spring MVC application then a Portlet spec compliant container is going to give you a lot right out of the box.

SURF does not mandate a remote invocation from a framework perspective. It’s easy to conclude from what is provided out of the box that this is the case given the bias on webscripts but it is also very possible to implement other types of renders and from there consume local resources, spring bean based resources.

It’s a nice marketing article, but really when you get down to actually developing on Liferay in my experience it is far from pleasurable.

The built-in portlets are extremely messy, with java scriptlets scattered all over the JSP pages, the architecture doesn’t use dependency injection properly, instead relying on calls to static util classes which makes it very difficult to debug and fix anything. If you use the service builder it creates method signatures that are longer than I would like an entire class to be. There are no comments in the code (and I mean none) and the code is not self documenting in the slightest. There’s also no decent technical documentation for the code/architecture.

If you’re just deploying your own portlets to it as a container then it’s ok, but if you have to change anything that is built-in, or delve into the actual code then it quickly becomes a very painful way to go.

Thanks for the thoughts.

First I think the point of the post was that Liferay is much more than a portal. It’s a soup-to-nuts framework. It comes with scaffolding capability for creating database-driven applications, UI capabilities and many out of the box services. Some of these capabilities are stronger than others. I think there is little question that if you need to build an application that requires the kind of social frameworks and other services as well as the application aggregation that a portal provides, the Liferay framework is going to give you a very big boost in productivity.

On the subject of built-in portlets and the use of scriptlets: over time Liferay has built up its tag libraries and most recently, its use of client side UI based on JQuery. JSP based applications seems to be a preferred approach at Liferay but use of tag libs is definitely a best practice. There are portlets that have a lot of scriplets in them and I agree with you that it’s not ideal. My sense is that this is not the approach going forward.
With respect to the Dependency Injection concern, I’m note sure I follow how the static methods making debugging harder. The class loader proxies is not something I am a huge fan of and I would agree that they can make debugging more difficult — that is however a separate issue from the static method approach. Although Liferay uses Spring under the hood (which supports setter and constructor injection,) the IoC (inversion of control) pattern Liferay uses in their framework is more akin to a Service Registry (but without the lookup step.)
If I had to point to an issue here, it would be that the static method based services sort of imply that there is one service implementation that meets the service interface. Some might think that in practical terms this is generally the case anyway but I disagree. I think you want to either use setter injection or a registry that allows you to get after more than one implementation. Long story short. I don’t think what Liferay is doing is “Wrong.” It doesn’t use Spring the way many projects do but this is mainly due to the fact that Liferay pre-dates Spring’s dominance. Also, it’s important to note that there is a lot of re-factoring in this area of Liferay still in play.
On documentation, I think the Service Builder methods should have more. Service Builder does allow you to add comments to many of the files it creates - and that capability should be used.

I hope to convey the sense here that we’re not just blogging for marketing effect. We’re not going to say that every last thing about Liferay is perfect. But let’s face it… no project is perfect. The best you can hope for is that the project is a) useful and, b) actively making progress. Brian Chan and Co. at Liferay work as hard as anyone I know at making their platform better with each release. IMO there is no doubt that Liferay can deliver value and that it can save you time and money. I’ve had both good and bad experiences with Liferay. It’s not the right framework for every need — and that’s the key. Liferay has a lot of features that tend to draw folks in. You need to ask hard questions about what you’re trying to do and what you actually need — and then go with the framework that gets you there with the right balance of time, cost, and runway.

-R

Russ,
Great post! I have just started to look at Portal Frameworks.I am looking towards developing a pilot singles dating site. I am a bit lost with deciding how to pick the framework that is right for me?Are there are any cardinal rules that you go by that could help with the process?

Hi Russ,
I found your article to be informative, and precise. I have recently been given the task of using Intalio BPM suite which uses Liferay. I will need to build portlets using Icefaces. I have extensive Richfaces/JBoss experience and have just updated myself in portlets. Generally I tend to use Spring/Hibernate/Facelets/Richfaces in most projects. I have to architect a solution in this new environment, so I have a number of questions. Like which is the best server for deployment of Lifray, I can see that many servers are supported, but what is the best one as per your opinion in terms of performance and ease of use. I read a bit on developer feedbacks and some are keen on using Glassfish bundle as it posses less amount of hassles for development and deployment. I was rebuilding the liferay source files, and I wanted to make changes to the database structure, such as User table, and I was unsure about the outcome, like where all these changes should be reflected, or maybe to add features like licensing for each user. I can’t find any documentation on the internals. What will be the consequences to other PHP/Scripting if changes are made to core files ? Since I don’t use these technologies and not a part of my skill set or that used by my company will it pose any immediate problems if we were to disable support for other languages for leaner code. Are any core modules working in PHP which may be affected by these changes. How do I propagate these changes to the database to the services layer ? Do I change existing code ? Can I remove those services I don’t require safely ? Is there some outline on support files for each specific language implementation, so we can safely remove or disable unused services. Is there some good guide to assist us on the internals of liferay. I have created UML models to better understand the working principles. But I think I am still a long way from rewriting them. Your assistance is greatly appriciated.

Thanks !

Warm Regards,
Ruben.

Seriously, the java community can learn something from a usability perspective from CMS systems like TYPO3, yes it’s PHP.

I spend around 2 days figuring out how theming works and layout templating and seriously, creating two war files to make theme is just way off. ANY non technical person should beable to create a theme in there favorite CMS. TYPO3 provides the excellent Templavoila system as an example. You just get a template, map it in TYPO3 and off you go. you don’t need to put ANY markers, engines or what not in it. If you get a new template from teh designer (given that the ID’s are the same) you just drop it in a folder and your website will use that! Also the fact that a template is full with portal rubbish like application.css, portlet.css, wiki images , progress bar images etc etc…

When I try to look at it from a users perspective the screens in liferay looks messy and un-organized.

Form and presentation is quite nice for people that don’t know, it allows you to define a custom way to present specific content.

When looking for a scripting language, I don’t see anything in there, at least not by default, items like menu rendering is not in Liferay. It has some items like ‘Navigation’ But doesn’t allow you to decide WHAT should be in the navigation.

What I really don’t like is how content is edited IN the web-page currently for a designer this means you need to make much more CSS so it looks presentable. By default it looks horrible.

Currently I give Liferay still a change, but if you say TYPO3 has a steep learning curve, then better get double ready for Liferay!

Ries

For 2 days I’ve been trying to figure out how to build porlets with Liferay using PHP. It does support development of simple PHP scripts, but that’s about it.

Not sure about any other languages, but with support of PHP? it really SUCKS!.

All thru out the day I was in
the community forum, and trying to figure out, what? how? and why?

Many PHP questions were given answers that of which can’t be exactly called an “answer”, others were never answered at all.

Saying that it supports was just for marketing, I guess… other non-java web developers won’t appreciate something like this from an open-source view.

Hi Reynolds,

I’m not sure how much PHP is exposed in Liferay but it’s based on Quercus PHP which is a full PHP 5 implementation written in Java. Quercus PHP is awesome if you ask me. It doesn’t support every last feature — but most are supported.

“Working out to integrate OpenLDAP in Liferay to incorporate single sign-on feature” Looking for a inputs.

Thanks,
Anil