The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 329

Find JSRs

• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs
My JCP
Register for Site
Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JCP Info
• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Status: Maintenance
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0


Description:
The Portlet 2.0 Bridge defines the semantics for executing JavaServer Faces views within a portlet.

Updates to the Original Java Specification Request (JSR)

The following changes have been made to the original proposal.

2015年06月16日:
The JSR Transfer Ballot was approved, and the Maintenance Leadership of the JSR has changed to Liferay.

Maintenance Lead: Neil Griffin

E-Mail Address: neil.griffin@liferay.com

Telephone Number: +1 407 312 7409

Fax Number: -

2015年05月28日:
The Maintenance Lead has requested a JSR Transfer Ballot, to transfer the Maintenance Lead role from Oracle to Liferay. As part of this, the JSR has moved to JCP 2.9.

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle Corporation

Name of Contact Person: Don Deutsch

E-Mail Address: donald.deutsch@oracle.com

Telephone Number: +1 650 506 2275

Fax Number: -

Specification Lead: Michael Freedman

E-Mail Address: michael.freedman@oracle.com

Telephone Number: +1 650 506 4904

Fax Number: -

Initial Expert Group Membership:

Andy Bosch
Matt Brasier
Raschka Christian
Shankar Djeyassilane
HIPPO
Oracle
SAP AG
Sun Microsystems
Red Hat Middleware LLC
TIBCO Software
Kito D. Mann
Martin Marinscheck
Thomas Spiegl
Icesoft Technologies
Shashank Tiwari
eXo Platform SAS
Adobe Systems Inc.

Supporting this JSR:

Adobe Systems Inc.
Andy Bosch
Matt Brasier
eXo Platform SAS
ICEsoft Technologies Inc.
Kito Mann
Martin Marinschek
Christian Raschka
Red Hat, Inc.
SAP AG
Sun Microsystems, Inc.
TIBCO Software Inc.
Shashank Tiwari

Section 2: Request

2.1 Please describe the proposed Specification:

The Java Portlet 2.0 Bridge for JavaServer Faces 1.2 Specification defines the required behavior of a control environment designed to run in a JSR 286 portlet and JSF 1.2 runtime. Its control behavior allows a JSF application/view to be accessed as a Java portlet.

Because the portlet bridge lies between the portlet container and the Faces runtime, its behavior and function depends on the semantics each expresses and supports. Differing versions of either the Portlet specification or the Faces specification requires a distinct bridge specification and implementation to fully express all available function. Though JSR 301, in defining the Portlet 1.0 Bridge for JavaServer Faces 1.2, provides a solid base for a Portlet 2.0 bridge the following new features in portlet 2.0 require a distinguished specification:

* ability to serve a resource directly from a portlet
* ability to send and receive events
* ability to define and operate on public render parameters
* ability to wrap portlet requests and response objects
* ability to use dispatch.forward.

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

At a minimum any platform that supports JSR 286 portlets and JavaServer Faces 1.2. Each of these dependent systems have a minimum requirement of running in a Java EE 5.x environment.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

At a minimum any platform that supports JSR 286 portlets and JavaServer Faces 1.2. Each of these dependent systems have a minimum requirement of running in a Java EE 5.x environment.

Should this JSR be voted on by both Executive Committees?

No.

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

This will standardize the execution of JSF artifacts as portlets providing consistency and interoperability which should greatly enhance the desirability of implementing portlets in JSF.

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

JSR 301: The Portlet 1.0 Bridge for JavaServer Faces 1.2 defines the function of a bridge running in a Portlet 1.0 and Faces 1.2 environment. Portlet 2.0 introduces a wide variety of new features that Faces applications can and/or should access. This specification builds on the base of the Portlet 1.0 specification to expose these new features. In addition its explicitly tuned to the tweaks and clarifications defined in Portlet 2.0 to provide a more effective and natural expression of behavior than could be achieved in Portlet 1.0.

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

The Portlet 2.0 Bridge for JavaServer faces 1.2 provides a transformation service, mapping between JSR portlet semantics and JSF MVC semantics. This specification standarizes this mapping behavior, though not the mapping implementation.

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

javax.portlet.faces package name will be used for API specifications.

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

No.

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

No.

2.11 Are there any internationalization or localization issues?

No.

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

No.

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

To be determined by the expert group, initial target is to have a working EG by spring 2009, an early public draft by spring 2009, a complete public draft by fall 2009 and a final version by mid 2010.

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

E-mail discussion, teleconferencing as needed (likely regular -- weekly/bi-weekly), and occasional face-2-face meetings.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

Transparency will be achieved by releasing regular (early) public drafts of the specification as the work progresses and by tracking, updating and posting an accurate schedule.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

stand-alone

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

The license will be a free-of-charge open source license compatible with Java EE licensing.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

We currently anticipate that the specification license will be the standard JCP specification license. The RI will be licensed under the Apache 2.0 distribution license and the TCK will be an Oracle specific license that will grant the licensee a nonexclusive, nontransferable, royalty-free limited license to use the programs solely for purposes of compliance verification/testing.

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.

List existing documents, specifications, or implementations that describe the technology. Please include links to publically available material.

JSR 301: Portlet 1.0 Bridge for JavaServer Faces 1.2 (Proposed Final draft)

JSR 286: Java Portlet Specification 2.0

JSR 252: JavaServer Faces Specification 1.2

This is an implementation of Portlet 2.0 Bridge on which the first Early Public Draft of the specification will likely be based:

Apache MyFaces Portlet 2.0 Bridge implementation

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

The JSR 301 specification will provide the foundation for this specification. This specification should merely be a recasting of the JSR 301 specification taking into account the changes between portlet 1.0 and portlet 2.0. This will include both new function and changes/enhancements to existing function.

The Portlet 2.0 specification and JavaServer Faces 1.2 specification guide and constrain the development of this specification. That is since the purpose of this specification is to define a bridge between these two containers, each of these container's specification will guide how the function is expressed.

The Apache MyFaces Portlet 2.0 Bridge implementation is the location of this specifications RI. As development of both this specification and RI have been underway for some time under the auspices of JSR 301 (with the prior blessing of the JCP). This implementation reflects both the current understanding of the bridge function as well as will be the location for future expression as the specification matures.