Blogging Roller

w.bloggar test. Further tests.

nntp//rss test post

<img src="http://hibernate.bluemars.net/tpl/hibernate2/img/hibernate_logo.gif" alt="Hibernate logo"/>

This blog is now powered by Hibernate. The upgrade went smoothly. Those asking about how Hibernate compares to Castor will have to wait a bit, I'm focusing on Roller 0.9.7 development right now and I may not have time for comparisons until after the release.

As Matt reports, I have finished the Roller-Hibernate implementation and committed it to CVS. Tonight, I will upgrade this site to the latest code from CVS. Matt wants to know how it works, but I don't know yet. Hibernate has been a pleasure to work with and the results seem fast, but I have not done any benchmarks yet.

Right now, Roller has a pluggable persistence layer with two implementations Hibernate and Castor. I'm not sure how long that will last as it is no fun maintaining two implementations of the very same thing.

Dominic Da Silva points out that Roller has been added to Out-of-the-Box.

Dominic Da Silva: While reviewing the updated Out-of-the-Box 2.0 package listing, I noticed Roller in there. Well done Dave, seems they see Roller as a value added app to any Java developer's software list.

Red Hat has released another Java product: the Red Hat Enterprise Portal Server. The product seems to be closely related to the Redhat Content Management System (formerly the ArsDigita Community System). I say this because the whitepaper was written by former ArsDigita employees (Jim Parsons and Richard Li) and the process for developing a portlet involves writing PDL. The product includes porlets for discussion forum, document management, resource scheduling, tasks, bookmarking, and chat.

Given the anti-Java bias that I have noticed among many Linux devotees (and especially on Slashdot) over the years, I find it interesting and encouraging that all of the "Red Hat Enterprise Applications" (all two of them) are pure Java. Also, the Red Hat Web Application Framework is Java.

Brad '.Net Guy' Wilson: Oh, and isn't it interesting that the first wave of .NET rich client apps that we've seen have all been blazingly fast and look appropriate for the environment... that definitely has never been true of Java, even today 8 years after release. Microsoft has a real advantage here that they need to leverage, by encouraging people to get away from awful web UIs and get back to rich client/server UIs.

Ouch! Brad is talking about <a href= "http://www.hutteman.com/weblog/2003/04/06.html#000056">SharpReader, a new .Net based three-paned RSS aggregator. I'm downloading it now. The related posts feature looks really cool.

Update: OK, I'm sold. SharpReader is awesome. It has really leap-frogged Synderella.

Update: it does not seem to detect updated posts like Synderella and Aggie do.

The problem was that FreeRoller has two DNS names 'freeroller.net' and 'roller.anthonyeden.com' and Roller uses the Servlet API request.getRequestURL() method to determine the URLs for RSS feed permalinks. Normally, this would not be a problem. You enter the freeroller.net address in your aggregator and you always get permalinks the to freeroller.net domain.

After Roller started caching RSS feeds, this became a problem. Sometimes RSS feeds would be cached with the freeroller.net address and sometimes they would be cached with the roller.anthonyeden.com address. If your aggregator recieved a copy of a feed at 1PM with the freeroller.net address and the same unchanged feed at 2PM with the roller.anthonyeden.com address, it would be fooled into thinking that every news item in the feed had been updated because the permalinks are different.

I fixed this by changing Roller so that it determines it's base URL only once and then stores this URL in the ServletContext as an attribute. There is still a risk that when Roller is restarted, feeds will appear to have been updated depending on whether the first request is for freeroller.net or roller.anthonyeden.com. Anybody have a better solution?

Bryan Field-Elliot suggests adding a configuration parameter so that a Roller admin can specify the 'base URL for RSS permalinks'. Sounds good to me.

For a number of reasons, I'm trying to come up to speed on Portal technology and the status of the Java Portlet API specification. I've done a little research and this is what I have gathered so far. Your comments and corrections are welcome.

What is a Portal?

A Portal is a web site that provies a starting point for access to information and applications. Registered users of a Portal are able to create their own personal views of the Portal and are able to customize both the content and layout of these views. A Portal Server provides the infrastructure for building a Portal. A Portlet is a component that plugs into a Portal Server and may then be included in a users personal views.

The Porlet API specification

The Java community has been working to standardize Portal technology for years now. So far there have been three JSR's for a Portlet API spec, JSR-162 which was withdrawn, JSR-167 which was withdrawn, and now JSR-168 which has been cooking for over a year now. JSR-168 is still private, but a public draft is expected any day now.

The Portlet API specification will make Portlets the fundamental unit of execution in a Portal Server just as the Serlvet API made Servlets the fundamental unit of execution in a Web Application Server. If you write your Portlet using the Portlet API, you'll be able to deploy it without code changes to any standard Java Portal Server just as you can deploy a Servlet to any Java Web Application Server.

Portal Servers and the Reference Implementation

The abscence of a Portal Server standard has not stopped the big J2EE players from pushing ahead with Portal Server products. Here is a quick summary of the offerings from the big players:

• Jakarta: Jetspeed - Based on the Turbine Framework. Javadocs.
• IBM: Websphere Portal - based on Jetspeed. Has it's own Portlet interface. Javadocs.
• BEA: Weblogic Portal - has it's own Portlet interface. Javadocs.
• Sun: Sun One Portal Server - doesn't define a Porlet interface. Javadocs.

Every Java spec is accompanied by a Reference Implementation (RI) and often the RI is released as an open source product.  Stefan Hepper of IBM, who is the Specification Lead for the Portlet API has proposed a new Jakarta sub-project called Pluto to develop an RI for the Portlet API. Pluto will be implemented using technology from the existing Jakarta Jetspeed product. Jetspeed committer Andy Oliver has done a nice job of summarizing the various mailing lists discussions concerning Pluto on the Pluto Talk Page.

Speculation

The Portlet API is still a secret guarded by the Java Community Process, but it is likely that the final API will look a lot like the Websphere Portal's API. After all, the specification lead works for IBM, Jetspeed is favored for the RI, and the Websphere Portal is based on Jetspeed. Based on this speculation, the best source for information on Portlet development is probably IBM's Websphere Portal Zone.  There you will find a recent interview with the lead architect of the Websphere Portal team, a very recently revised Portlet Development Guide, and an article on Developing a Struts Application for Websphere Portal 4.2.

Update: Floyd Marinescu wrote in to recommend a ServerSide article Portal Standards by Thomas Schaeck and Portlet API spec lead Steffan Hepper.

I made it to the RTP Bloggers lunch today at my new favorite lunch place Crazy Fire mongolian grill. Bruce Loebrich has a <a href= "http://radio.weblogs.com/0104308/2003/04/03.html#a2932">nice write up of the event. Also, Ken Coar has posted some pictures of the attendees chewing food, picking noses, and etc. Apologies to Sam Ruby and John Beimler, but I thought this was a funny exchange:

John Biemler: Did you hear Bruce Eckel said SOAP sucks?
Sam Ruby: who's Bruce Eckel?

FreeRoller has been up since Monday morning at 7:44AM EST and it is still snapping along. Maybe Roller ain't half bad afterall. Thanks Anthony and thanks JavaLobby!