A Liferay conference is a heck of a lot different than a WebSphere conference.

When you’re at a WebSphere conference, users are all filled with nightmare stories about some aspect of working with WebSphere. Whether it’s page aggregation accelerators that don’t work in their portal product, or the ridiculous development process that kills the development cycle with painfully long test server startup, there’s no shortage of horror stories.

A Liferay conference is different. At a Liferay conference it’s more of a love in. Everyone is excited about the new features and the new direction, and everyone seems to be encouraged by the way the product is evolving. Don’t get me wrong, I’m not saying that Liferay is perfect, but there is a discernable difference between the mood of the Liferay developer and the mood of the WebSphere developer.

I spoke about this observation with Vivek Agarwal, a  Liferay advocate at Xtivia, and he told me that he could easily rhyme off a number of reasons as to why Liferay developers were happier developers. In the following article, Vivek puts forth his top ten reasons as to why a Liferay developer is a happier developer.

About Ten Reasons to Love Liferay Portal

If lack of foreign keys, transactions, relationships are your cup of tea and you like filling your jsp's with scriptlets that invoke static methods on services then maybe you could be happy developing on liferay.

For the rest of us, at best it can be tollerable

If lack of foreign keys, transactions, relationships are your cup of tea and you like filling your jsp's with scriptlets that invoke static methods on services then maybe you could be happy developing on liferay.

For the rest of us, at best it can be tollerable

Whatever it's limitations, there is simply no way it can't be better than WebSphere. Even a three-legged horse is faster than a dead one.

I'm guessing you are referring to the service builder tool in your post (apologies if not) but I would make the following points:

Point 1: service builder is a  code generation tool for use in building out Liferay portlets not Liferay itself - it's optional to use. I'm not a great fan of code generation but I appreciate the option whether or not I choose to use it.

Point 2: foreign keys, transactions and relationships are all possible in Liferay whether you use the service builder tool to generate portions of your code or not. 

Not sure what your point about scriplets invoking services refers to but the choice of how you build out the portlet front-end is up to the developer. i.e. you can write the portlet how you want as long as it is to the portlet spec.

If it's the 'core' portal codebase then I agree that you have to decide whether or not this is an issue. My opinion would be that I'm not likely to be near that code so unless it has security implications (does it, or is it just not what you consider good practice) I can live with it for the functionality I get from Liferay.

There is vendor specific functionality/APIs bundled with the Liferay portal but again this is up to you whether you use it. In the main I am happy to trade off not writing and testing significant portions of code for the benefit of using a portlet like Liferay where appropriate. 

My experience of Websphere and Oracle portals would also lead me to agree with the point of the main post.

Yes i was referring to service builder among other things. And no you do not have to use it. However it's what they teach you to use in ther documentation, trainings and books. Not to mention that the platform itself is built on top of it. Yes.. anno 2012 these people are teaching developers to write code like <%= List cats = CatLocalServiceUtil.getCats(); %> in their jsp's

But sure you can have transactions, relationships and everything if you use liferay exclusively as a portlet container and do not integrate with it too tightly but that also takes away many of the benefits you might get from using liferay. 

But even then know that the underlying platform is also built on this foundation, and the number of bugs you encounter show it.

Ps. the original blog post had some damning commentary

I liked this comment > Let's agree to disagree. I can't tell you how sick and tired I am of having to explain to the customer that they've hit yet another bug in Liferay. I am willing to wager that you can't name a single non trivial feature in liferay that isn't severely broken in one way or another (try me!)

It is always a pleasure to inform the customer that they've hit a Liferay bug in some trivial part of the functionality. Oh yes, we'll have to write an EXT to patch that. That will cost you 3 days development time. It's a Liferay bug. Yes I know our consultants told you it is the best product since the 5 blade gillette :-).

Still good to know that Websphere is even suckier as a product.

I'm genuinely interested to know why anyone would consider using a technology (JSR 168/286) that had its genesis in J2EE 1.4. One would think, in 2012 we have better choices - is iGoogle, my Y! built on Java portal technology?

Have you looked at jsr286? What don't you like about it ? I actually like the portlet api's quite a lot, it's just a shame there's no really good and readily available portal servers out there.

I think we, the Java development community need to take a serious look at the state of Web development with Java - with the possible exception of Play Framework which is still maturing the rest of the frameworks does not have any traction in a modern development shop. Java portlets and Portal servers make that story even worse - FYI, first draft of JSR 286 was ratified in late 2005 back when J2EE 1.4 was considered state of the art. Much of the raison d'être for portal - SSO, Portlet events, WSRP, content aggregation can be achived with other, easier technologies. As for portlet APIs the whole goal was interop, right? Show me one non trivial portal application that you can port from one portal server to another without significant effort. It's not much unlike the whole JCR APIs for CMS integration - who cares about writing to a JAva API to pull content out of an external CMS now that much more lightweight, web protocol based interop is available, i.e., CMIS. Eventually the portlet APIs will go dodo like some other equally misguided JSRs like JBI and JCR which take the  naive view that all that gets used in an enterprise is Java. 

Yes I would agree the Play framework looks very interesting but it's certainly not the only (potentially) viable web framework for a 'modern development shop'. If anything the real criticism is that there are too many web frameworks to choose from and this leads to a fragmentation of knowledge across the Java development community and unconstructive preaching about personal favourites.

JSR 286 addressed the wide spread criticisms of the original spec. This was needed and most people agree that it resolved them fairly successfully. It was ratified in 2008 not 2005 - so after Java 6 and when many of the JEE6 APIs where maturing. The question I normally ask when evaluating something is 'does it server it's defined purpose', not how old it is! What do you feel it still lacks/needs added/removed?

SSO, Portlet events, WSRP, content aggregation can be achieved by other technologies - sure - and maybe easier - I'm not sure how but if you can tell me how then please do. But that doesn't invalidate them being available in a Portal server.

One of the main reasons for using a portal server is not interop - in the same way as using Hibernate may allow you to swap out databases - it's more of a theoretical benefit than a real one - but to provide a single point of user interaction and simplify how applications and content are delivered in a secure and consistent manner. There are also considerable system integration benefits that can be gained in a lot of cases.

There are many other user cases for using a portal server - but this to me is the main one most medium to large companies make the decision on.  

Also, the JCR API predates CMIS so it's really not a fair criticism to say that there is now a 'better' way. The JCR API helped the evolution of the Java community when it came to working in a structured way with content management systems/requirements. Should we no longer use JMS because AMQP is available or are these decisions/questions more complicated than this? I would suggest so.

In the context of this thread Liferay is CMIS compliant and was an active participant in its evolution. So really the point here should be that Liferay has been keeping up with the wider (non-Java) technology evolutionary cycle.

100% agree, portal is garbage. Been using it for almost 2 years now and it's a major constraint in our development team. However the option between liferay or websphere I'd take liferay, not because it's any good but because well IBM just sucks at doing pretty much anything...

Yes, if someone forces me to use a Java portal I'd pick LifeRay over IBM (I might even quit my job) but that's not saying much. As for JSR 286 check out the dates when the first public draft was published - that was 2005. But let's not wrangle about dates - show me one Java EE 6 feature that has gone into JSR 286. While I agree the latest and greatest is not we should look for my point was we all know how bloated and cumbersome J2EE was before Java EE 5 and knowing that would we want to lock ourselves into a product whose architecture is built on those technologies? Is it any wonder then why they hog resources, run like a pig because under the covers they are generating tons of cruft. As for the portal value-adds:

SSO -  why go in with a half-based SSO solution from a Portal when you can leverage a full identity/access management stack should you need those 'enterprise class' features. OpenAM is quite solid and free.

Content aggregation - In this day and age of JQuery UI, client side widgets and mashups why would I need a portal?  

WSRP - Stuff your entire user interface into a SOAP envelope? Seriously?  

Portlet events - solution looking for a problem.

As for interop, sorry, what I meant was portability which is the touted reason for JSR 286. Proof is in the pudding as to how portable it is. It's not entirely a theoretical benefit - while swapping out databases does not happen often, no customer likes to get stuck with a product they would not be able to get rid of. JMS is actually a good example - customers do change their middleware technologies and JMS has proven to be a good insurance though it falls short in interop, not being a wire level protocol.

I'm not knocking on LifeRay, I know it supports all the relevant standards but it's inescapable that the core technology it's built on is bloated and outdated.

The whole portlet life cycle is based on "Web page refresh", which is no longer relevant in this age of Ajax and RIA.

I agree with you again George...all based on web page refresh

graphic designer holiday gifts

I have worked with WebSphere Portal and Liferay Portal quite intensely. Let me list out some of the list of problems I faced with Liferay

1. Liferay auto-packaging mechanism: This is one of the most an.l features of Liferay. Why on earth should I have to process a portlet (war file) by putting it through a pre-processing mechanism is beyond me. This means I cannot simply take a war file and deploy it on to a server as is. It also does not support EAR files by the way. So if you want to package multiple war files within an ear, no chance. The only way is to pre-process all these individual war files first and then package them into an ear for deployment.

2. No automation whatsoever - Talk about a school boy program that has suddenly attracted so many people in the world. If I need to automate page creation, roles, web content, portlet configuration etc., how many interfaces do I have - none, except for another an.l feature called LAR file that does not work most of the times. Someone has to sit and do a manual export and import of LAR files. Does Liferay support JMX extensions or any other automation framework? 

3. Has anyone looked into the Document Library features of Liferay EE 6.0 before calling this product good? There is no concept of workspaces although the underlying Jackrabbit allows multiple workspaces. But Liferay stores all folder information (DLFolder) into the Liferay database instead of the Jackrabbit workspace. This means although you store files under multiple Jackrabbit workspaces, the list of folders will still come from the Liferay DB causing confusion as to why I cannot download a file if the workspace I use is still pointing to the default Liferay workspace.

Contrary to all the the above, WebSphere Portal allows a mature automation framework that can be used for full automation. Supports a mature JCR based file and web content management system and can take both WAR and EAR file deployments as is. WebSphere Portal is aimed for enterprise customers not at cowboys.

Liferay is just so up there that its more distinct

club stork