This project has retired. For details please refer to its
Attic page
Pluto – Welcome to Pluto
Last Published: 2023-12-21
Welcome to Pluto
Portlet 3.0 API
Portlet 2.0 API
Portlet 1.0 API
JSR 362 JCP Page
JSR 286 JCP Page
JSR 168 JCP Page
The Pluto Project
About Pluto
Mission
News
Security
Status
Architecture
Resources
FAQ
Wiki
Issue Tracker (JIRA)
Get Involved
Pluto 3.1
MVCBean Portlets
Getting Started
Maven Archetypes
Deploying Portlets
Portlet Concepts
Version 3 Features
Using the TCK
Release Notes
Pluto 3.0
Getting Started
Deploying Portlets
Portlet Concepts
Version 3 Features
Using the TCK
Release Notes
Pluto 2.0
Getting Started
Deploying
Embedding
Release Notes
App Servers
Pluto 1.1
Getting Started
Deploying
Release Notes
Subprojects
Overview
Project Info
Project Summary
Project Team
Project License
Mailing Lists
Source Repository
Issue Tracking
Welcome to Pluto
Get Pluto 3.1.2
Pluto 3.1.2
Installation Guide
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.
Introducing MVCBean Portlet Development
(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.
Pluto implements a Portlet Container
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.
Pluto Provides a Light-Weight, In-Memory Portal
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
How Portlets Differ from Servlets
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.
Copyright © 2004–2023
Apache Software Foundation