Just not thinking in portals

The last few days I’ve been looking into portals and portlets, specifically JSR168 compliant ones.
Reason: Our new intranet runs as a portal and they would like some additional developers working on it.

So I started looking around. The concept is really cool. You have a site the displays content: The portal. It provides things like authentication and page layout. You then have portlets that display information. They rely on the portal to provide a way to store state and session information, but they can do anything else you want with them. They don’t have to worry about how they are presented, just that they present some information.
In the world of cool ascii:

______________
|    PORTAL    |
|  ___    ___  |
| |   |  |   | |
| |___|  |___| |
|____\____/____|
      \  /
    PORTLETS

I had a look at a few of them (pluto, jetspeed, liferay, uPortal) and was disappointed from a development point of view. I have grown fond of the hot code replacement when developing j2ee application with tomcat. I would be able to debug and change logic. I could update jsps and have them recompile the next time I hit refresh in the browser. It is great. I wanted to do the same thing with portlets since it is really just an extension of servlets.

Pluto is the apache reference implementation of a portal server. It provides the basics to get a portlet running and visible on screen. Sounds like just what I am after. Unfortunately, to get portlets deployed to the portlet container, you have to provide pluto specific configuration information for pluto to detect your portlet. This is going to hinder development rather than assist.

Jetspeed was really easy to setup and get going. I had a play around with this one a little more because it was really easy to get into. Layouts where easy to play with, colours, portlets where all just simple to add to the page. From a site building tool perspective. It was great. I deployed the testsuite from the Pluto project to find out what it was like deploying additional portlets. Deploying was ok. But when I started testing these portlets, performance seemed to have taken a walk. My cpu usage would just skyrocket for a few seconds and then stop when the page returned. Whilst Jetspeed didn’t have to have any specific configuration information in the portlet to get it to load, the only way that a portlet does become registered is if you deploy to the portlet container. This means every time I want to make a change, I have to bundle my portlet and deploy. This would also hinder development rather than assist.

Liferay is very similar to Jetspeed and I feel sorry that I am discussing it after Jetspeed because I am just going to brush over it. I played with it for a while because it had the same usable simplicity that came with Jetspeed. The only difference I noted was that when I deployed the testsuite, it didn’t seem to suffer the same performance slowdown. Since I still have to deploy every time I make a change to my application, it’s not going to help development.

I couldn’t get uPortal to work out of the box, so there is not really much I can say. But it does raise an important point. If you have something that you want the world to use, it has to work out of the box. You have to be able to download, unzip and start. The hypersonic database is really cool for providing a light database that works just connecting to it.

So I was disappointed. I couldn’t believe that I had to jump through hoops to get an portlet to be recognised by the container. So I spent some time looking into how why they can’t determine the portlet information automatically. ServletContext has a getContext call which takes the context path, but it doesn’t seem like there is a way to find out all of the contexts deployed to the application.

So, there is my rant on Java portals and portlets. Most of the information I’ve been reading is from 2003-2006 which is kinda disappointing. Either I am looking in the wrong places or JSR168 portlets haven’t taken off. I am going to take a second look to see if I can find a way to list all of the contexts because when I first looked I thought I seen an old method that has been deprecated and just returns null, but now I can’t see it.

-= Comments
1. Xavier | September 30th, 2007 at 10:19 pm
oh god we used Oracle Portal with portlets to build My.Swinburne and there were so many headaches. Maybe that was the oracle bit and not the JSR bit. It was a while ago so I don’t have any useful criticism save to say I’m sufficiently burned that I’m staying well away from any job to do with portlets…