preface I first came across the Java Portlet technology in 2006. I was working on a data ware- housing project, and data from different sources was managed by a portal application. My first encounter with the technology wasn't a pleasant one--I faced issues with inter-portlet communication, Ajax, file downloading, and so on. After a lot of strug- gles and analysis, I was able to get past the limitations inherent in Portlet 1.0 by build- ing ad hoc solutions involving Java servlets to address the business requirements. The design of these solutions resulted in a highly complex system that was hard to main- tain and understand. It left me feeling that the Java Portlet technology wasn't ready for developing web portals in the real world. But even though Portlet 1.0 ( JSR -168) had limitations, it didn't stop businesses from taking advantage of the benefits web portals offered--personalization and con- tent aggregation. The lack of support for some critical features in the Java Portlet technology meant that portlets had to rely on portal server­specific extensions, which resulted in portlets that were not portable across different portal servers and were not Portlet 1.0­compliant. In 2008, Portlet 2.0 ( JSR -286) was released, and it addressed the limitations that existed in Portlet 1.0. Portlet 2.0 was a major step forward in the adoption of Java Port- let technology. The portlet technology received a further boost when portlet bridges made it possible to develop applications using existing web frameworks like JSF , Wicket, Struts, and so on, without learning the Java Portlet technology. Towards the beginning of 2009, I started working on a portal project using Port- let 2.0. Unlike the early days, I no longer had to worry about developing Ajax port- lets or implement ad hoc approaches to perform inter-portlet communication. I felt xix