Hubbry Logo
Java Portlet SpecificationJava Portlet SpecificationMain
Open search
Java Portlet Specification
Community hub
Java Portlet Specification
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Java Portlet Specification
Java Portlet Specification
Java Portlet Specification
View on Wikipedia
from Wikipedia

A Java Portlet Specification defines a contract between portlets and their containers; they provides a convenient programming model for Java portlet developers. It is defined through various Java Specification Requests (JSRs).

Background

[edit]

Portlets

[edit]
Main article: Portlet

A portlet is a pluggable user interface software component that is managed and displayed in a web portal. A portlet responds to requests from a web client with and generates dynamic content. Some examples of portlet applications are e-mail, weather reports, discussion forums, and news.

Portlet containers

[edit]

A portlet is managed by a portlet container, which runs portlets and provides them with the required runtime environment. A portlet container receives requests from the portal to execute requests on the portlets hosted by it.

Specifications

[edit]

Portlet standards are platform independent application programming interfaces that are intended to enable software developers to create portlets that can be plugged into any portal supporting the standards. An example is the Java Portlet Specification. A Java portlet resembles a Java Servlet, but produces fragments rather than complete documents, and is not bound by a URL. A Java Portlet Specification (JSR) defines a contract between portlets and the portlet container. JSRs provides a convenient programming model for Java portlet developers.

JSR 168

[edit]

The Java Portlet Specification V1.0 was developed under the Java Community Process as Java Specification Request JSR 168, and released in its final form in October 2003.[1]

The Java Portlet Specification V1.0 introduces the basic portlet programming model with:

  • two phases of action processing and rendering in order to support the Model–View–Controller pattern.
  • portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate
  • window states, indicating the amount of portal page space that will be assigned to the content generated by the portlet
  • portlet data model, allowing the portlet to store view information in the render parameters, session related information in the portlet session and per user persistent data in the portlet preferences
  • a packaging format in order to group different portlets and other Java EE artifacts needed by these portlets into one portlet application which can be deployed on the portal server.
  • Portal development as a way to integrate the different web-based applications for supporting deliveries of information and services.

Portlet Catalog

[edit]
  • Initially Java portal vendors had their own portlet development framework thus those portlets were confined to specific portal servers and couldn't be deployed to the rest of the Java portals. After JSR 168 inception, Java portlets may be deployed on any Java portal servers adhering to JSR 168 specifications.
  • A Portlets Catalog is a set of portlets that are ready-to-use components for enterprise portals. For those who want to adopt portals certainly need many and variety of portlets to deploy and run. Here Portlets catalog are of use.
  • A JSR 168 portlets catalog makes sure that portlets under this catalog may run on any standards–compliant Java portal server. Types of portlet solution (vertical domains and technology) like collaboration, social networking, community, content management, utility, calendaring, HRM all are available in these catalogs.
  • There are many open source and commercial Portlets Catalog available but JSR 168 based solutions are rare.
  • JSR 168 specifications offer suitability to the developers to reuse the code to maintain a set of JSR 168 compliant portlets. For deployers, it's easy to keep a single set of solution and deploy it on many.

JSR 286

[edit]

JSR-286 is the Java Portlet Specification v2.0 as developed under the JCP and created in alignment with the updated version 2.0 of WSRP. It was released in June 2008.[2] It was developed to improve on the short-comings of the version 1.0 specification, JSR-168. Some of its major features include:[3]

  • Inter-Portlet Communication through events and public render parameters
  • Serving dynamically generated resources directly through portlets
  • Serving AJAX or JSON data directly through portlets
  • Introduction of portlet filters and listeners

JSR 362

[edit]

JSR-362 is the Java Portlet Specification v3.0 and was released in April 2017.[4] Some of its major features include:[5]

  • Resource Dependencies
  • Explicit Render State
  • CDI 1.2 Integration
  • Servlet 3.1 Alignment
  • Portlet Hub & XHR IPC
  • FacesBridge Integration via JSR 378[6]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Java Portlet Specification

View on Grokipedia
from Grokipedia
The Java Portlet Specification is a standardized and programming model developed under the (JCP) that defines the contract between portlet containers and Java-based portlets, enabling developers to create reusable, modular for generating dynamic content fragments within portal environments. Portlets, as Java technology-based , are managed by a portlet container that handles their lifecycle—including initialization, action processing, rendering, and destruction—while ensuring interoperability across different portal servers and vendors. The specification originated with JSR 168 in October 2003, which introduced the foundational Portlet 1.0 standard for vendor-independent portlet development, followed by JSR 286 in 2008 for Portlet 2.0, adding features like event coordination, shared parameters, and resource serving for enhanced inter-portlet communication. JSR 362, finalized in April 2017, advanced to Portlet 3.0 with alignments to Java EE 7, support for WebSockets, improved mobile and client-side capabilities, and extended eventing to meet evolving web and portal needs while maintaining . As part of the transition from Java EE to under the , the specification evolved into Jakarta Portlet, with version 4.0 under development as of 2025 to migrate and update the Portlet 3.0 APIs for the modern ecosystem. Key aspects of the specification include its lifecycle phases—action (for modifying state), event (for inter-portlet signaling), render (for content generation), and (for serving non-HTML assets)—which allow portlets to produce markup fragments aggregated into a single portal page, typically in or other formats. It also standardizes deployment via WAR files, security models, and integration with protocols like Web Services for Remote Portlets (WSRP), promoting pluggable UI components for enterprise portals. This framework remains influential for building scalable, personalized web applications, with reference implementations like Pluto supporting its adoption.

Overview

Definition and Purpose

The Java Portlet Specification is a standard developed through the (JCP) that defines application programming interfaces (APIs) for portlets, which are pluggable user interface components designed to generate fragments of markup content for aggregation and composition within a portal page. These portlets function as modular web components, enabling developers to create dynamic, reusable content pieces that can be integrated into larger portal applications. The primary purpose of the specification is to enable the integration of reusable and dynamic content in environments, supporting personalization of user experiences and the aggregation of multiple applications—such as clients, feeds, and productivity tools—into a unified interface. By standardizing the deployment and management of portlets across compliant portal servers, it facilitates seamless content delivery and in distributed systems. Unlike servlets, which typically generate complete web pages in response to HTTP requests, portlets produce only markup fragments and adhere to a defined with the portlet container for request handling and lifecycle management, making them optimized for portal-based compositions. Portlet containers serve as the runtime environment that orchestrates these components within a portal page. Key benefits of the specification include standardization for enhanced , allowing portlets to be developed once and deployed across multiple portal vendors without proprietary adaptations, and strong alignment with the broader Java EE (now ) ecosystem for robust enterprise application development. This promotes efficiency for developers, independent software vendors, and end users by broadening the availability of portable portal applications.

Historical Development

The Java Portlet Specification began with the proposal and approval of JSR 168 by the (JCP) initiated with the JSR Review Ballot in January 2002, culminating in its final release on October 27, 2003. This inaugural standard emerged to resolve the interoperability challenges posed by proprietary portal technologies, enabling portable portlet development across compliant containers. Building on this foundation, JSR 286 was proposed in November 2005 and released in June 2008 as Portlet Specification 2.0, following final approval in early 2008, addressing limitations identified in version 1.0 through community feedback while incorporating support for contemporary web technologies such as AJAX. The update aimed to enhance portlet capabilities without breaking , fostering broader adoption in enterprise environments. JSR 362 followed, proposed in March 2013 and finalized in April 2017 as Portlet Specification 3.0, integrating advancements from Java EE including and Servlet 3.1 to modernize the framework for evolving web and mobile paradigms. In September 2017, Oracle announced the donation of Java EE to the , prompting the rebranding to and necessitating namespace transitions from javax to jakarta across specifications, including portlets, with ongoing stewardship under . As of November 2025, the transition to Jakarta Portlet 4.0 progresses with initial API specifications released in early 2025 following its creation review in April 2025 and API migration in May 2025; 11 was released on June 26, 2025, though the complete Jakarta Portlet 4.0 specification continues development to align with the 11 platform.

Fundamental Concepts

Portlets

A portlet serves as the fundamental building block in the Java Portlet Specification, functioning as a pluggable Java web component that generates dynamic content fragments for aggregation within a portal page. It is implemented as a Java class adhering to the javax.portlet.Portlet interface, which outlines the essential contract for processing requests and producing responses in a standardized manner. To streamline development, portlets commonly extend the javax.portlet.GenericPortlet abstract class, which supplies default implementations for lifecycle methods and handles common tasks like request dispatching based on portlet modes. Portlets are bundled into web application resource (WAR) files for deployment, incorporating the compiled classes, static resources, and a required portlet.xml deployment descriptor file that configures the portlet application. This descriptor defines critical metadata for each portlet, such as localized display names, supported portlet modes (e.g., view, edit, help), and initialization parameters passed to the portlet's init method at startup. It also specifies security constraints to implement role-based access control, restricting access to portlet resources based on user roles defined in the portal environment. State management in portlets relies on distinct data models to balance with user . Render parameters, encapsulated in RenderRequest, provide a read-only mechanism for passing state information across render requests, ensuring consistent view generation without server-side persistence. Portlet preferences, managed via the PortletPreferences interface, allow for user-specific, persistent configurations stored in a backend repository, modifiable through edit mode. Session attributes, stored in PortletSession, support temporary state across multiple requests and enable inter-portlet communication within the same user session. A representative example is a basic "Hello World" portlet that extends GenericPortlet and overrides the doView method to produce a simple fragment. The implementation sets the response content type to text/[html](/page/HTML) and outputs markup like:

java

public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException { response.setContentType("text/[html](/page/HTML)"); PrintWriter out = response.getWriter(); out.println("<div class=\"portlet-section-body\">Hello, World!</div>"); }

public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException { response.setContentType("text/[html](/page/HTML)"); PrintWriter out = response.getWriter(); out.println("<div class=\"portlet-section-body\">Hello, World!</div>"); }

This fragment is then integrated by the portlet container into the portal page, illustrating the modular nature of portlets in composing cohesive user interfaces.

Portlet Containers

A portlet container is a Java EE-compliant server component that provides the runtime environment for executing and managing portlets, analogous to a servlet container for servlets. It is integrated into application servers such as via extensions like Apache Pluto or embedded within full portal platforms like , where it hosts portlet applications to generate dynamic content for portal pages. The primary responsibilities of a portlet container include aggregating requests from multiple portlets to compose a single portal page, dispatching incoming HTTP requests to the appropriate portlets, and enforcing the portlet contract defined by the specification. This involves managing portlet instances, providing access to shared resources, and ensuring that portlets adhere to the defined APIs for content generation and interaction. For instance, when a user accesses a portal page, the container coordinates the rendering of fragments from various portlets into a cohesive response. To ensure compliance, a portlet container must fully implement all APIs outlined in the Java Portlet Specification, including support for deploying portlet applications as standard Web Application Archive (WAR) files containing portlet deployment descriptors. It also manages portlet contexts, which encapsulate the environment for a specific portlet application, providing configuration data, initialization parameters, and resource access similar to servlet contexts but tailored for portal aggregation. Compliance is verified through tools like the Portlet Technology Compatibility Kit (TCK). Notable implementations include Apache Pluto, the official that demonstrates the specification's requirements and serves as a basis for testing. Commercial examples encompass HCL Digital Experience (formerly IBM WebSphere Portal), which integrates the container within its framework with version 9.5 current as of 2025, and Oracle WebCenter, offering advanced composition and security features built on the standard. Unlike servlet containers, which handle complete HTTP responses for standalone web applications, portlet containers support portal-specific features such as page composition from multiple portlet fragments, multi-portlet coordination via , and rendering in isolated modes without direct control over the full HTTP response. This enables reusable UI components within aggregated portal environments rather than independent pages.

Portlet Lifecycle and Modes

The Java Portlet Specification defines a lifecycle for portlets that governs their execution within a portlet container, ensuring consistent management of resources and state changes. The lifecycle begins with the init(PortletConfig config) method, which the container invokes once after instantiating the portlet to perform initialization tasks such as setting up resources or loading configurations. Following initialization, the portlet enters an active phase where it processes requests, and it concludes with the destroy() method, called by the container to release resources and clean up state before the portlet instance is removed from service. This lifecycle model, introduced in JSR 168, supports the deployment of portlets as reusable components in portal environments. Central to request handling is a multi-phase model for processing and rendering, expanded from the initial two phases in Portlet 1.0. The action phase, via processAction(ActionRequest request, ActionResponse response), handles user interactions like form submissions to update state, set parameters, or change modes without generating output. The event phase, introduced in Portlet 2.0 (JSR 286), uses processEvent(EventRequest request, EventResponse response) for inter-portlet communication through events and public render parameters, enabling coordination across portlets. The render phase invokes render(RenderRequest request, RenderResponse response) to generate markup based on the current state. Additionally, the resource phase, also from Portlet 2.0, employs serveResource(ResourceRequest request, ResourceResponse response) for serving dynamic resources such as images, scripts, or AJAX responses without full page rendering. This model ensures consistent portal page aggregation. Portlet modes define the functional state of a portlet during rendering, indicating the type of content or interaction it provides. The specification mandates support for the view mode, where the portlet generates its primary markup reflecting the current state, such as interactive screens or static content. Optional modes include edit, for customizing portlet behavior like setting preferences, and help, for displaying assistance information such as documentation or tooltips. Developers can define custom modes beyond these standards, though support depends on the portal implementation; unsupported modes are ignored during processing. Modes are typically switched via action requests and influence the rendering logic in the render method. Window states control the visual presentation and space allocation of a portlet window on the portal page, affecting how content is rendered. The normal state represents the default configuration, where the portlet shares the page with others and limits output to accommodate shared display space. In the maximized state, the portlet expands to occupy more or all available space, enabling richer or fuller content presentation. The minimized state restricts the portlet to minimal or no content output, typically showing only the title bar. These states can be altered programmatically during the action phase and are standardized in JSR 168 to promote interoperability across portals. In practice, the lifecycle and modes integrate through a typical flow: a user interaction triggers an action or event request, where state updates occur (e.g., saving form data or signaling other portlets). The then invokes render or phases for affected portlets, producing the updated view in the appropriate mode and state. This ensures thread-safe, aggregated rendering without concurrent modifications.

Evolution of Specifications

JSR 168: Portlet Specification 1.0

The JSR 168, formally known as the Portlet Specification version 1.0, was finalized and released on October 27, 2003, through the (JCP). The expert group, co-led by and , included representatives from organizations such as , , , and to develop a standardized for Java-based portlets. This specification established the foundational contract between portlets and their containers, enabling interoperability across different portal servers while aligning with the Servlet Specification 2.3 and JSP 1.2 standards. At its core, JSR 168 introduced a two-phase rendering model to support the Model-View-Controller (MVC) pattern in portlet development. In this model, the action processing phase handles user interactions and updates the portlet's state without generating markup, followed by the rendering phase where the portlet produces content fragments for aggregation into a portal page. Portlets could operate in different portlet modes to manage various user interactions: view for displaying primary content, edit for user customization, and help for providing assistance information. Additionally, window states controlled the portlet's space allocation on the page, with standard states including normal (shared space with other portlets), minimized (reduced to a title bar), and maximized (expanded to fill the page), along with defined transitions between them. Data handling in JSR 168 emphasized persistent and transient state management. The Portlet Preferences API allowed developers to store and retrieve user-specific settings on a per-portlet-instance basis, enabling such as layout adjustments or content filters that persisted across sessions. Render parameters facilitated passing state information between and rendering phases or across requests within the same portlet, ensuring stateless operation while maintaining for dynamic content generation. Deployment followed a standardized approach using a portlet.xml deployment descriptor to configure portlet definitions, including modes, states, init parameters, and supported content types. Portlets were packaged as Web Application Archive (WAR) files, integrating seamlessly with J2EE application servers for distribution and deployment in compliant containers. While JSR 168 provided a robust basic model for portlet development, it lacked support for inter-portlet communication mechanisms and dynamic serving of resources like images or scripts directly from portlets, limitations that influenced subsequent enhancements. The reference implementation for this specification was Apache Pluto 1.0, an open-source portlet container that demonstrated compliance and served as a testing ground for developers.

JSR 286: Portlet Specification 2.0

The Java Portlet Specification 2.0, formalized under JSR 286, was approved as a final release on June 12, 2008, by the (JCP). This version maintains binary compatibility with the preceding JSR 168 (Portlet Specification 1.0), ensuring that existing portlets could continue to function without modification while introducing enhancements for improved interoperability and integration with emerging web technologies. The specification's primary goals included aligning the portlet API with Java EE 5 standards and Web Services for Remote Portlets (WSRP) 2.0, thereby facilitating better coordination among portlets and support for remote syndication in distributed environments. A major advancement in JSR 286 is the introduction of inter-portlet communication mechanisms, including events and , which enable portlets to coordinate actions and share state without . Events provide a publish-subscribe model where portlets can declare and process typed events during the action phase, allowing responses to state changes across portlets or even web applications, with completing before rendering begins to maintain consistency. extend this by permitting shared, bookmarkable parameters (e.g., via HTTP GET) defined in the deployment descriptor, supporting coordination such as filtering search results across multiple portlets on the same page. Additionally, the ServeResource method allows portlets to serve dynamic resources like AJAX responses or data independently of full page renders, enhancing support for asynchronous interactions with configurable caching levels (FULL, PORTLET, or PAGE). Further enhancements include portlet filters, which intercept and modify requests similar to servlet filters, declared via deployment descriptors for tasks like logging or compression. Container runtime options, such as XML escaping configurations, provide finer control over portlet behavior, while portlet listeners enable notifications for lifecycle events like mode changes. Preference handling was improved with support for validators to ensure during storage and retrieval. was bolstered through propagation of the security context to resource serving and alignment with Java EE 5's role-based access controls, ensuring protected access to dynamic content. These features collectively advanced modern web integration, such as Web 2.0-style interactions. JSR 286 saw widespread adoption in enterprise portals, powering asynchronous and event-driven architectures in implementations like Apache Pluto (the reference implementation) and commercial servers from vendors including and , where it remains a foundational standard for Java-based portal development.

JSR 362: Portlet Specification 3.0

JSR 362, known as the Portlet Specification 3.0, was finalized and released on April 12, 2017, by the (JCP) to update the portlet standard in alignment with advancements in Java EE 7 technologies. This version addresses limitations in the preceding JSR 286 (Portlet 2.0) by enhancing integration with contemporary enterprise Java standards, such as improved and asynchronous processing, thereby boosting developer productivity in building modular web applications. The specification maintains full with Portlet 2.0 APIs, allowing existing portlets to deploy on 3.0 containers without modification, while introducing targeted deprecations for future evolution. A major enhancement is the integration of Contexts and (CDI) 1.2, enabling dependency injection directly into portlet classes, filters, listeners, and even asynchronous threads. This includes new custom scopes—@PortletSessionScoped for session-wide access, @PortletRequestScoped for request-specific instances, and @RenderStateScoped for managing render-phase state across requests—to simplify resource management and promote reusable components. Additionally, the specification aligns with Servlet 3.1 by adding asynchronous support for resource requests through the PortletAsyncContext interface, which facilitates handling long-running operations without blocking the main thread, thus improving in enterprise portals. Resource handling sees significant improvements, particularly for client-side dependencies like libraries and CSS stylesheets. The @Dependency annotation allows portlets to declare external resources that the container automatically serves and manages, reducing for loading shared assets across portlets. Explicit render state management is further refined with annotations such as @HeaderMethod, @RenderMethod, and @ServeResourceMethod, which support flexible method signatures and by allowing these methods to reside in distinct classes, easing maintenance in complex applications. Inter-portlet communication (IPC) advances through the introduction of the Portlet Hub API, a client-side JavaScript interface that enables asynchronous interactions via (XHR), building briefly on the server-side event system from JSR 286 to support dynamic updates without full page reloads. This API allows reading and writing render parameters, executing actions, and generating resource URLs in an Ajax-friendly manner, enhancing in composite portals. Complementing this, integration with FacesBridge 2.0 (JSR 378) leverages Portlet 3.0's new HEADER_PHASE in the portlet lifecycle to better support JavaServer Faces (JSF) 2.2 portlets, ensuring seamless bridging for JSF-based components within portlet environments. To streamline development, Portlet 3.0 introduces annotation-based configuration via @PortletApplication and @PortletConfiguration, eliminating the need for verbose deployment descriptors in many cases and aligning with modern Java EE practices for declarative setup. These changes collectively focus on developer productivity by reducing configuration overhead and enhancing modularity, while preserving the core portlet contract for enterprise-grade portal applications.

Transition to Jakarta EE: Portlet 4.0

Following Oracle's announcement in September 2017 to transfer stewardship of Java EE to the , the platform underwent a rebranding to , beginning with version 9 in 2020, which introduced the namespace shift from javax.* to jakarta.* to enable open governance and future evolution under the . Jakarta Portlet 4.0 represents the migration of the JSR 362 APIs—serving as the baseline for Portlet 3.0—from the javax.portlet.* namespace to jakarta.portlet.*, with an initial emphasis on maintaining compatibility rather than introducing major new features, adhering to semantic versioning principles to support incremental updates. The development timeline for Jakarta Portlet 4.0 began with a project proposal submitted to the on March 24, 2025, followed by a successful creation review on April 16, 2025, marking the official start of the specification project under Eclipse's processes. As of November 2025, the full specification remains under active development, with early artifacts, such as Maven dependencies, made available to facilitate testing and integration. This transition is essential for ensuring compliance with future Jakarta EE releases, notably impacting portal implementations like DXP, which began adopting Jakarta EE 10— including Portlet 4.0 support—starting with its 2025.Q3 release to leverage enhanced security and modularity. Backward compatibility for legacy applications is supported through bridging mechanisms that allow mixed javax and jakarta environments during phased migrations. However, challenges include updating dependencies in existing portlet applications to resolve namespace conflicts and ensuring alignment with aligned specifications, such as 6.0, which shares similar migration requirements.

References

  1. https://www.oracle.com/java/technologies/intro-java-portlet-specifications.html
  2. https://portals.apache.org/portlet-api/portlet-api-2.1.0/javax/portlet/Portlet.html
  3. https://www.jcp.org/en/jsr/detail?id=362
  4. https://jakarta.ee/specifications/portlet/
  5. https://jcp.org/en/jsr/detail?id=168
  6. https://jcp.org/en/jsr/detail?id=286
  7. https://jakarta.ee/specifications/portlet/4.0/
  8. https://objectcomputing.com/resources/publications/sett/august-2006-jsr168-the-portlet-specification
  9. https://portals.apache.org/pluto/
  10. https://learn.liferay.com/w/dxp/development/traditional-java-based-development/core-frameworks/portlets
  11. https://help.hcl-software.com/digital-experience/9.5/CF227/extend_dx/portlets_development/wpsbpc/
  12. https://docs.oracle.com/cd/E28280_01/webcenter.1111/e10148/jpsdg_portlets_intro.htm
  13. https://jcp.org/en/jsr/detail?id=[168](/page/168)
  14. https://portals.apache.org/portlet-api/portlet-api-2.1.0/javax/portlet/PortletMode.html
  15. https://www.infoworld.com/article/2160766/introducing-the-portlet-specification-part-1.html
  16. https://portals.apache.org/portlet-api/portlet-api-2.1.0/javax/portlet/WindowState.html
  17. https://www.oracle.com/java/technologies/portlet-specification1-v20.html
  18. https://docs.huihoo.com/javaone/2007/java-ee/TS-4225.pdf
  19. https://portals.apache.org/pluto/v301/v3Features.html
  20. https://www.jcp.org/en/jsr/detail?id=378
  21. https://eclipse-foundation.blog/2017/09/12/java-ee-moves-to-the-eclipse-foundation/
  22. https://projects.eclipse.org/proposals/jakarta-portlet
  23. https://projects.eclipse.org/projects/ee4j.portlet/reviews/creation-review
  24. https://mvnrepository.com/artifact/com.liferay.jakarta.portlet/com.liferay.jakarta.portlet-api/4.0.0
  25. https://learn.liferay.com/w/reference/jakarta-2025-faq
  26. https://learn.liferay.com/l/36177075
  27. https://learn.liferay.com/w/dxp/development/tooling/liferay-workspace/upgrading-to-jakarta
  28. https://www.surekhatech.com/blog/migrate-java-ee-to-jakarta-ee-liferay
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.