In the last months I had the nice and interesting opportunity to try out several portal servers – ranging from open source to the big commercial ones. As a summary upfront, the first time experience of nearly all solutions is REALLY ANNOYING; in some cases it’s unbelievable how poor and confusing everything is. Just as a disclaimer, this is my personal opinion after playing around with these servers for just a short time.

But let’s be more precise…I started with looking for open source portal servers implementing the JSR 286. Due to bad experience in the past I avoided the JBoss portal (this might be unfair as my experience is two years old.). Apache Jetspeed does not support the standard yet, so I looked for Exo and Liferay. I think their web sites are overloaded, they look too much like a brochure for me and getting to the real downloads requires too many clicks.

After downloading Exo, I found a nice README in the root directory which tells you briefly how to start the portal and what the admin credentials are. Nice and easy. Unfortunately after starting the whole thing, I got lost as I found no way to deploy my portlet. Afer downloading the docs (again some clicks) I found out that the downloaded version does not support the deployment of portlets through the UI. I think deployment through the UI is a number one feature. So I immediately stopped here and went to Liferay.

They have the same shiny web site, sigh, and after downloading you have “something” extracted. The provided README is the Apache Tomcat README, so no real clue about how to start this thing. As I’m able to start Tomcat and know the default port I could get the portal running easily. Looking for the admin credentials required to download the docs and search for it. It took me some more reading that for Liferay everything is a plugin, even a portlet. So I uploaded my portlet through the UI and got it running immediately. I didn’t found any spec related problems with my portlet, however the AJAX based UI of Liferay seems to have sometimes problems with render parameters.

Then it was time for the commercial ones. Fortunately I had someone else downloading and installing WebSphere and Weblogic Portal for me and providing me the admin credentials. Of these two, WebSphere is slow, has an overloaded admin UI, but deploying your portlet through the UI is nice and easy. I didn’t found any spec related problems. Nothing more to say about this one 🙂

But the nightmare of every portal developer is Weblogic Portal. It seems to be even slower than WebSphere, is full of bugs and has a more than overloaded and unstructured admin UI. There is no menu for deploying a portlet. So I went to the website, and really got lost. It took me some time to find a small guide explaining how to deploy JSR 168 portlets…hmm but I had a 286 portlet. Ok, let’s try it anyway. The unbelievable thing is that the UI for uploading a portlet is not linked from the portal admin console. It seems that this vendor is rather ashamed of having this. And after you type the secret url in your browser, you know why. Honestly, I’m really bad in doing nice looking html pages, but I think I could have done even this one better. Ok, good looking is not important in this case, so I ignored that and happily uploaded my portlet. Then I knew why these things cost a fortune….it took the server three minutes to deploy my little portlet – at least that’s what was displayed after three minutes. So back to the real admin console and trying to find my latest deployed stuff…hmm, where is it? Ok, consulting the same docs again, it explained that I have to configure a WSRP provider. Wait a minute…did you say WSRP, like in WSRP = Web Serices for Remote Portlets? Oh well, my portlet is running locally (hopefully), so it makes sense to configure something running remotely. Indeed. Shrug, just follow the docs and you will find success…of course, not! Ok *something* is wrong. Now, if you’ve seen one of these server beasts you know that they have a separate server console where you can see and configure millions of things (the more configurations you have the better the product is, I guess), so after several clicks I found out that my portlet application had not been deployed correctly. How could this be? It wasn’t my fault, so it should be the servers fault..ok to keep a really long story short, in order to deploy a portlet application you have to copy it physically to the hard drive on the portal server, invoke the browser based UI and upload the application through the browser (again). This must be some strange security feature or one of those evil developers still laughing today in his cubicle about this funny joke he did. (Oh and btw, don’t use Firefox 3 to upload your portal applicaiton, the server is not capable of handling the requests correctly…but fortunately the server happily accepts the requests and pretends that everything is fine)

Ok, but the best part was still to come. I went back to the portal admin console, configured the WSRP consumer (still, can someone explain me why? – ok, I’ve an idea why it could be this way, but I think it’s wrong to impose technical decisions on the UI.). From here everything went smoothly, I configured the portlet, added it to the page, got some server crashes and broken pages and finally came to the page with my portlet. Remember that this was a JSR 286 portlet deployed through the JSR 168 import tool? Ah well, everything went fine until my portlet should render itself. Some wired exceptions occured.

After some experiments it turned out that the server exposes the portlet 2.0 API and is able to deploy portlets relying on this API and using the new deployment descriptor. And if you inspect the API version from within your portlet it confirms to be a 2.0 compliant portal server. BUT as soon as you invoke a 2.0 feature you get an exception. I have zero idea what the intension of such an implementation is. Perhaps it’s again this developer in his cubicle? Or is it a whole team making fun of dumb users like me?

So after reducing my portlet to just use JSR 168 features it nearly worked – except for some more quirks and errors in the implementation of the spec. As a summary, I don’t want to use the WebLogic Portal server again.

In general, Liferay seems to be a good open source solution, if they only would add a small README to the downloaded archve. Without a deployment functionality, Exo is of no interest for me. If you’re into complicated UIs, slow running servers with zillions of features noone needs, use WebSphere – forget about WebLogic. The portlet API 2.0 spec compliants seems to be given with Liferay and WebSphere. So now I’m waiting for Jetspeed to finalize their support 🙂