Jetspeed 1 and 2

Here’s an article about Jetspeed 2. I’m actually very excited about this, though I feel that compliance to the spec is overrated. Perhaps I’m not really an enterprise developer, but I haven’t seen very many situations where I wanted a portlet (or an EJB) that had been developed on one portal server and deployed to another. But some of the Spring oriented features and ability to deploy struts application war files as portlets seem pretty neat and useful.

I’m currently working on a portal application, and we’re using Jetspeed 1–version 1.5, which has extensive documentation and has actually been released. JS1 is built on the Turbine framework. I hadn’t done much looking at this (other than a glance when I was looking at Torque for an OR layer). But so far, I’ve been really really impressed with Jetspeed and Turbine.

What has most impressed me is the configurability of these frameworks. There are a set of properties files that specify services, things like logging, persistence, localization, session validation, and authentication. The developers have done a great job of breaking these up into well defined chunks and letting me subclass services and plug in my own implementations. One example: our users do not login to the portal. Rather, they are authenticated by another application, which sets a cookie. I was able to disable Jetspeed’s own authentication system (which looks to a database) and plug in mine without making any modifications to source code. With properties overriding, I didn’t even have to modify the default properties files. Fantastic.

Jetspeed supports both JSP and Velocity as templating languages for the view. Velocity is used throughout the default portal, and I decided to use it as well. It’s an interesting language which has a lot of the benefits I’ve read about Groovy–there’s no types, and methods and properties look the same. It does look a bit perlish, I’ll admit–lots of $ and #, but it’s been fun to learn a different view language.

JS1 also provides an easy framework for developing portlets–an MVC framework, in fact. I don’t want to repeat what the relevant section of the portlet tutorial says, so I’ll just mention that developing dynamic content is a breeze.

I don’t want to say that Jetspeed has been a pure joy, however. There were a few days a couple of weeks ago that I wondered whether it had been a good choice at all. We have an existing base of users (hence the alternate authentication) and were noticing that the portal was loading slow when running against a user table of around 100K users. Then I ran some tests with The Grinder and noticed it was running really slow. Like 30 seconds to render a page with 5 portlets. Luckily, some sleuthing around indicated that there was much extraneous database access going on, and when that was eliminated, performance became acceptable.

In addition, the default build process is mavenized. I had an extremely bad experience and ended up writing a simple ant build script to do what I want. It’d be nice if both were options–since lots of people come to JS1 looking to slap a portal together for cheap, rather than thrash around with a complex build process. (I’d say at least forty percent of the messages to the mailing list are build related–not a good sign.) I just went to a BJUG talk about Maven, and Thompson was persuasive, so I might give maven another chance.

All in all, though, I’ve been very happy with Jetspeed. I am looking forward to JS2; I wish the timing had been better so I could have used it on the current project.