Stefan Hepper, and Stephan Hesmer have written an article on the new Portlet spec. This specification defines the contract between portlet and portlet container, and a set of portlet APIs that address personalization, presentation, and security. The specification also defines how to package portlets in portlet applications. Part 1 of this two-part series describes the Portlet Specification and explains its underlying concepts.

The article goes into:

- An introduction to the Portlet Specification, and basics about portals/portlets.
- The portlet lifecycle
- The portlet modes
- Portlet window states
- User info, portal context, localization, and caching
- Packaging and deployment

Read Introducing the Portlet Specification, Part 1

Hmm... Interesting graph here :

http://www.javaworld.com/javaworld/jw-08-2003/images/jw-0801-portlet1.jpg

It talks about an Portlet Invoker API, which not included in the spec but that IBM will be contributing to the Apache Foundation (ie Pluto).

I hope this can become a defacto standard so it will allow smaller portal implementations, like Jetspeed, to run on all J2EE containers.

This is too early to ask but are there any JSR 168 "compliant" (as opposed to "compatible") implementations? If not, which one is likely to be the earliest available compliant implementation?

The specification itself is an extension of the servet API and just cover the basic interfaces to develop a portlet. Nothing is specified on how to implement your Portal Server and which set of features you shall provide to your end-users (personalization, SSO, CMS,...). So rushing on the first compliant portal server does not look like the best idea. Moreover the spec looks quite simple, so it shouldn't require a lot of work to implement. So all the Java based portal vendors will certainly offer a support of this JSR during Q4 this year or Q1 next year (and the vendors behind the JCP certainly in September as they already got all the time to implement it before community or public draft releases of the standard).

Stéphane

Sorry. Should have said "which one is likely to be the earliest available OPEN-SOURCE compliant implementation?"

I have read (in a reply to a previous TSS posting about the same topic) that Jetspeed is the RI for this JSR but could not find anything official to this effect on the JCP website. Also, the Jetspeed site does not mention anything about this either.

Jetspeed 2 will probably be the first open-source compliant implementation because the code is already available since a few days, but it is lacking the actual Pluto dispatcher, which will be contributed by IBM. My understanding is that IBM is doing some more testing and probably some legalese work on this release and wants to get it right. You can find more information about the status of Jetspeed 2 in the mailing lists, as this is very recent (about a week now)

Rickard has also said here that he was working on an implementation of the JSR-168, but I have no idea if he intends to open source it or not.

Liferay is an open source portal that will be supporting JSR 168. We began development as soon as the draft became available. Liferay won't be the first to finish the implementation, but will offer a richer set of default portlets. A demo can be found at http://my.liferay.com

And so http://jportlet.sourceforge.net/

> JSR-168, but I have no idea if he intends to open source it or not.

Yeah, I actually converted all our portlets to JSR168 yesterday, and it went well (haven't implemented it all yet, just the stuff we need for our own portlets). Looks good so far, but no, this is not OpenSource code. In the process I hope to be able to add Portlet API support to WebWork2 though, which is OpenSource.

Rickard,

How do you see that working? I've started reading up on the spec (just a little bit)... Are we talking about implementing a Portlet Container, or making it possible to implement Portlets with WW2 by creating a PortletDispatcher which implements the Portlet Interface, or something else?