The Apache Pluto project hosts the Java Portlet Specification Reference Implementation (RI) and Technology Compliance Kit (TCK). The current version (3.0) of this specification is known as JSR-362. The previous specification version, JSR-286, covers version 2.0 of the specification. The first version of the specification, JSR-168, established version 1.0. Pluto implements and is fully compliant with all three of these specifications.
(Since Apache Pluto 3.1.0): A large subset of the JSR 371 (MVC 1.0) Specification has been implemented which enables "MVCBean" portlet development. This feature is an open source proof-of-concept that could possibly serve as the basis for the next version of the Portlet Specification (3.1).
For detailed information, see the MVCBean Portlets page.
A portlet container provides a runtime environment for portlets implemented according to the Portlet API. In this environment portlets can be instantiated, used and finally destroyed. The Pluto portlet container does not work stand-alone like the servlet container; instead it is implemented as a thin layer on top of the servlet container and reuses servlet container functionality. From an architecture point of view, the Pluto portlet container provides an interface between the portal and portlets.
Pluto serves as the portlet container for many portals, including Apache Jetspeed. To accommodate the aggregation and display of diverse content in a dynamic manner, a portal such as Jetspeed must provide a framework that integrates the various pluggable parts into a consistent user interface for the portal user. The pluggable parts are called portlets. The contract, or programming API, between these portlets and a portal is known as the Portlet API. Pluto is the implementation of this contract or API.
Portlets are designed to be independent applications, just as servlets are. However, rather than producing a complete web page, portlets produce markup fragments that are intended to be aggregated with the output from other portlets to produce a complete portal page. Portlets can be developed without knowledge of the other portlets that the portal places on the resulting web page. They need only obey the syntactic and semantic rules laid out by the portlet specification.
The Pluto portlet container fully implements the Portlet API specification and offers developers a working example platform on which they can test their portlets. However, it is cumbersome to execute and test the portlet container without a driver such as a full running portal. To aid in portlet development and testing, and to provide a framework for testing the portlet container itself, Pluto provides a simple portal component that fulfills the requirements set out by the JSR 362 Portlet Specification 3.0 standard.
The term "in-memory" means that the Pluto portal component does not provide a mechanism for data persistence. For example, portlets may set portlet preferences, but Pluto does not persist the preference data across a server restart.
If you want to get started with rapid portlet development with Pluto, see the documentation on Developing with Pluto
In contrast to servlets, portlets may not do things like sending redirects or errors to browsers directly, forwarding requests or writing arbitrary markup to the output stream to assure that they don't distract the portal web application which uses them. Another difference compared to servlets is that portlets rely on portal specific infrastructure functions such as access to user profile information, standard interface for storing/retrieving persistent settings, getting client information, etc. Also, portlets are generally administrated more dynamically than servlets.
Download