Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 167: JavaTM Portlet Specification

This JSR has been Withdrawn
Reason: As there is very significant overlap between JSRs 162 & 167, Sun and IBM reached a mutual agreement regarding the proposals. They reached a point where they felt that they had a mutually acceptable new combined JSR proposal, which they then sought endorsement of from the existing supporters of JSR 162 and 167.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: A Portal is a web site that offers personalized content and services from different sources in a single place. This consolidation of content and services is normally referred as aggregation. The capability of selecting the content and services to display and their layout in the Portal page on user basis is usually known as personalization. An example of a Portal web site is

This specification will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security.

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Adam Abramski

E-Mail Address:

Telephone Number: +1 408 276 6378

Fax Number: +1 408 276 4283

Specification Lead: Alejandro Abdelnur & Wesley Budziwojski

E-Mail Address: & wesley.budziwojski@sun

Telephone Number: +1 408 276 5207 & +1 408 276 3594

Fax Number: +1 408 276-4283

Initial Expert Group Membership:


Supporting this JSR:

Cap Gemini Ernst & Young
Enformia Ltd.
Tarantella, Inc.

Section 2: Request

2.1 Please describe the proposed Specification:

The JavaTM Portlet specification will define a Portlet API that provides means for aggregating several content sources and applications front ends. It will also address how the security and personalization is handled.

It will define the different components for Portal Computing, their interaction, lifecycle and semantics. These components will comprise -but they will not be restricted to-:
Portlets, Desktop, Deployment descriptor, developer APIs, and vendor extension APIs for security, user customization, and layout management. The JavaTM Portlet specification will define the minimum set of possible states for a Portlet-such as normal, minimized, maximized, etc.- and the valid state transitions per desktop type. The JavaTM Portlet specification will define an extensible Layout management but it will only mandate a basic one.

This first version of the JavaTM Portlet specification will concentrate in the following design goals:

  • Client agnostic
  • Support for multiple types of clients
  • Support for multiple types of desktops
  • Automatic client type detection and desktop selection
  • Simple developer API
  • Support for Localization and Internationalization
  • Hot deployment and re-deployment of Portal applications
  • Declarative security (same as to the mechanism found in Servlet and EJB specs)

    The JavaTM Portlet specification will be built on top of the JavaTM Servlet specification. It is envisioned that the developer API will be similar to the JavaTM Servlet API.

    The Expert group will consider functionality such as support for, parallel execution of Portlets within the Desktop, logging, security and personalization.

    The Expert group will decide if the specification should include a set of specialized Portlet implementations for common tasks such as syndication (RSS), HTML scrapper, Web Services access, etc.

    The Expert Group will evaluate defining a Credential mapping service to allow the Portal application to access resources in other applications -not supporting the notion of distributed sessions- on behalf of user.

    It is understood that the subject of this JSR is already being addressed by Open Source projects and products from different vendors. The Objective of this JSR is to create a standard for Java Portal Applications, which will help unifying a fragmented area. The expert group will ensure this specification draws appropriately from such projects and products.

    2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

    A JavaTM extension for the J2EE 1.4 platform.

    2.3 What need of the Java community will be addressed by the proposed specification?

    This specification will establish a standard API for creating Portlets, thus avoiding locking in Portal developers in a specific implementation and allowing Portlets developers to reach a wider audience while reducing their development efforts.

    2.4 Why isn't this need met by existing specifications?

    While the Servlet/JSP specifications define an include mechanism for aggregating Servlets and JSPs, they do not define the Desktop metaphor where this aggregation happens. Neither the Servlet/JSP specifications define the possible states and transitions of an included Servlet or JSP, or how the state of one Servlet or JSP affects the display of the other included Servlets or JSPs. In addition, The Servlet/JSP specifications do not define a personalization interface or the idea of persisting the personalization information.

    The JavaTM Server Faces (JSR 127) aims to define a standard, MVC based, Web GUI framework focusing on the UI components (input fields, lists, buttons, etc.) and their event model. However, it does not address aggregation, security and personalization.

    2.5 Please give a short description of the underlying technology or technologies:

    The JavaTM Portlet specification will be designed leveraging the following technologies: XML, JAXP, Java Servlet/JSP, JAAS and other J2EE technologies.

    For example, JavaTM Server Faces could be used by a Portlet developer to render the Portlet's content. In addition, JavaTM Server Faces could be used by a Portal vendor to implement the rendering of the Portal desktop. For a description of the JavaTM Portlet technology, refer to section 2.1.

    2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


    2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


    2.8 Are there any security issues that cannot be addressed by the current security model?


    2.9 Are there any internationalization or localization issues?

    Yes. APIs and descriptors to support internationalization and localization are a fundamental design goal of this JSR.

    2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


    2.11 Please describe the anticipated schedule for the development of this specification.

    To be determined by the expert group, initial target is December 2002.

    2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

    We anticipate a mixture of mailing list and occasional face to face or teleconference meetings.

    Section 3: Contributions

    3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

    Different implementations are available today, the following list enumerates some of them:

    Apache Software Foundation: Jakarta JetSpeed 1.3

    BEA: Web Logic Portal 4.0

    IBM: WebSphere Portal 1.2

    iPlanet: iPlanet Portal Server 3.0

    Oracle: Oracle 9i Portal

    3.2 Explanation of how these items might be used as a starting point for the work.

    They will be useful for gathering features and evaluating the effectiveness and shortcoming of each implementation.