Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 378: Portlet 3.0 Bridge for JavaServerTM Faces 2.2 Specification

Updates to the Original JSR

The following changes have been made to the JSR since the original proposal:

2019.11.14:

2.5 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 JSF 1.2 environment.

JSR 329: The Portlet 2.0 Bridge for JavaServer Faces 1.2 defines the function of a bridge running in a Portlet 2.0 and JSF 1.2 environment.

Portlet 3.0 introduced a new HEADER_PHASE to the portlet lifecycle that must be utilized by the the JSR 378 bridge. Specifically, the JSF lifecycle must be invoked from the HEADER_PHASE rather than the RENDER_PHASE (as was the case with the JSR 301 and 329 bridges). This is necessary because the JSF 2.x lifecycle has the ability to add resources to the head section of an HTML page. With Portlet 3.0, adding resources to the head section of an HTML page can only be accomplished in the HEADER_PHASE.

Portlet 3.0 introduced the CDI "bean portlet" feature along with CDI scopes including @PortletRequestScoped, @PortletSessionScoped, and @RenderStateScoped. The JSR 378 bridge must be compatible with registration and execution of bean portlets and must also support @BridgeRequestScoped as an annotation that enables CDI to manage a bean that is scoped from an action request to a subsequent render request.

Incorporating other features of Portlet 3.0 (such as Inter-Portlet Communication (IPC) via XmlHttpRequest) are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR.

Most of the features introduced by JSF 2.0/2.1/2.2 are implemented and handled by the JSF runtime. The JSR 378 bridge simply invokes the JSF runtime within the context of a portlet environment. Therefore, the JSR 378 bridge will depend on the JSF 2.2 API and extension points only as necessary. For example:
- Implement javax.faces.context.ExternalContext
- Implement javax.faces.application.ResourceHandler
- Handle the file upload requirements of h:inputFile

Some new features introduced by JSF 2.0/2.1/2.2 (such as flash scope, resource library contracts, and stateless views) are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR.

Handling certain incongruities between the JSF lifecycle and portlet lifecycle are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR. For example, calling ExternalContext.getRequestContentLength() during the event, header, or render phases of the portlet lifecyle is not possible since only the action and resource phases can determine such a value from the underlying ClientDataRequest.

Support for third-party component suites is beyond the scope of this JSR. Notwithstanding, implementations of the JSR 378 bridge may support third-party component suites in an implementation-specific manner if desired.

2019.05.13:
The Specification Lead and Expert Group decided to move from JCP 2.10 to JCP 2.11.


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Liferay, Inc.

Name of Contact Person: Neil Griffin

E-Mail Address: neil.griffin@portletfaces.org

Telephone Number: +1 877 543 3729

Fax Number: +1 877 543 3729


Specification Lead Member: Liferay, Inc.

Specification Leads: Neil Griffin

E-Mail Address: neil.griffin@portletfaces.org

Telephone Number: +1 877 543 3729

Fax Number: +1 877 543 3729


Initial Expert Group Membership:

- Liferay, Inc.
- Oracle Corporation
- IBM
- ICEsoft Technologies, Inc.
- Leonardo Alfredo Uribe Panesso, Irian Solutions GmbH
- Cagatay Civici (Individual)
- Kito Mann (Individual)
- Josh Juneau (Individual)

Supporting this JSR:

- Liferay, Inc.
- Oracle Corporation
- IBM
- ICEsoft Technologies, Inc.
- Leonardo Alfredo Uribe Panesso, Irian Solutions GmbH
- Cagatay Civici (Individual)
- Kito Mann (Individual)
- Josh Juneau (Individual)
- Werner Keil (Individual)



Section 2: Request

2.1 Please describe the proposed Specification:

The Java Portlet 3.0 Bridge for JavaServer Faces 2.2 Specification defines the required behavior of a control environment designed to run in a JSR 362 portlet and JSR 344 runtime. Its control behavior enables JSF applications to be accessed as Java portlets.

Because the portlet bridge lies between the portlet container and the JSF 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 functionality.

This Specification is a follow-on to JSR 329 which defined the requirements for a Portlet 2.0 bridge for JavaServerTM Faces 1.2.

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

At a minimum any platform that supports Portlet 3.0 and JavaServer Faces 2.2. Each of these dependent systems have a minimum requirement of running in a Java EE 7 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 Portlet 3.0 and JavaServer Faces 2.2. Each of these dependent systems have a minimum requirement of running in a Java EE 7 environment.

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

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

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

JSR 301: The Portlet 1.0 Bridge for JavaServerTM Faces 1.2 defines the function of a bridge running in a Portlet 1.0 and JSF 1.2 environment.

JSR 329: The Portlet 2.0 Bridge for JavaServerTM Faces 1.2 defines the function of a bridge running in a portlet 2.0 and JSF 1.2 environment.

Portlet 3.0 will introduce new features such as Inter-Portlet Communication (IPC) via XmlHttpRequest that JSF portlet developers will want to utilize without extra configuration. JSF 2.0/2.1/2.2 introduced a variety of new features that JSF portlet developers require such as the Facelets View Declaration Language, Ajax processing, resource handling, view scope, flash scope, etc.

Note that this information has been updated from this original proposal.

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 JSF 1.2 environment.

JSR 329: The Portlet 2.0 Bridge for JavaServer Faces 1.2 defines the function of a bridge running in a Portlet 2.0 and JSF 1.2 environment.

Portlet 3.0 introduced a new HEADER_PHASE to the portlet lifecycle that must be utilized by the the JSR 378 bridge. Specifically, the JSF lifecycle must be invoked from the HEADER_PHASE rather than the RENDER_PHASE (as was the case with the JSR 301 and 329 bridges). This is necessary because the JSF 2.x lifecycle has the ability to add resources to the head section of an HTML page. With Portlet 3.0, adding resources to the head section of an HTML page can only be accomplished in the HEADER_PHASE.

Portlet 3.0 introduced the CDI "bean portlet" feature along with CDI scopes including @PortletRequestScoped, @PortletSessionScoped, and @RenderStateScoped. The JSR 378 bridge must be compatible with registration and execution of bean portlets and must also support @BridgeRequestScoped as an annotation that enables CDI to manage a bean that is scoped from an action request to a subsequent render request.

Incorporating other features of Portlet 3.0 (such as Inter-Portlet Communication (IPC) via XmlHttpRequest) are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR.

Most of the features introduced by JSF 2.0/2.1/2.2 are implemented and handled by the JSF runtime. The JSR 378 bridge simply invokes the JSF runtime within the context of a portlet environment. Therefore, the JSR 378 bridge will depend on the JSF 2.2 API and extension points only as necessary. For example:
- Implement javax.faces.context.ExternalContext
- Implement javax.faces.application.ResourceHandler
- Handle the file upload requirements of h:inputFile

Some new features introduced by JSF 2.0/2.1/2.2 (such as flash scope, resource library contracts, and stateless views) are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR.

Handling certain incongruities between the JSF lifecycle and portlet lifecycle are beyond the scope of this JSR and may be handled by a maintenance release and/or subsequent JSR. For example, calling ExternalContext.getRequestContentLength() during the event, header, or render phases of the portlet lifecyle is not possible since only the action and resource phases can determine such a value from the underlying ClientDataRequest.

Support for third-party component suites is beyond the scope of this JSR. Notwithstanding, implementations of the JSR 378 bridge may support third-party component suites in an implementation-specific manner if desired.

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

The Portlet 3.0 Bridge for JavaServerTM Faces 2.2 provides a transformation service, mapping between the portlet lifecycle and JSF lifecycle. This specification standardizes this mapping behavior, though not the mapping implementation.

2.7 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 (same as JSR 301 and JSR 329)

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

No.

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

The Java Portlet 3.0 Bridge for JavaServer Faces 2.2 Specification must ensure the following:
- Section 5.2.3 of the Specification titled "Determining the Target View" must require that the target viewId be restricted to valid filename characters.

2.10 Are there any internationalization or localization issues?

No.

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

No.

2.12 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 Q2 2015. The completion of this specification depends on the completion of the JSR 362 specification which is ongoing at the time of this writing.

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

E-mail discussion, teleconferencing as needed. Face-to-face meetings should not be needed.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

- Is the schedule for the JSR publicly available, current, and updated regularly?
The schedule will be publicly available at the JSR 378 community tab: https://jcp.org/en/egc/view?id=378

- Can the public read and/or write to a wiki for the JSR?
Comments by non Expert Group members will be possible via the Observers Mailing List.

- Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
Comments will be responded to via the Observers Mailing List.

- Have you spoken at conferences and events about the JSR recently?
Liferay has spoken at JavaOne 2014 and JavaOne 2013 about portlets based on JSF 2.2.

- Are you using open-source processes for the development of the RI and/or the TCK?
The RI and the TCK will both be developed using an open-source process.

- What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
http://www.java.net/javanet-web-site-terms-use

- What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.
https://issues.liferay.com/browse/JSR378

- What is the mechanism for the public to provide feedback on your JSR?
Comments by non Expert Group members will be possible via the Observers Mailing List.

- Where is the publicly-accessible document archive for your Expert Group?
https://java.net/projects/faces-bridge-spec/downloads

- Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?
Yes

- Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?
@FacesBridgeSpec https://twitter.com/FacesBridgeSpec

- Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)?
Feedback would be welcome regarding all aspects of the specification, RI, or TCK.

2.15 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.

The RI and TCK will be stand-alone projects available at GitHub. When complete, the API and Implementation JARs will be published to Maven Central.

2.16 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).

Previous versions were stand-alone, and this new version will be stand-alone.

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

The Final Release Specification will have a license similar to the JSR 362 license: https://www.jcp.org/aboutJava/communityprocess/licenses/jsr362/IBM-Specification-License-JSR-362.pdf

The RI and TCK will be licensed under the Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

https://java.net/projects/faces-bridge-spec/lists/jsr378-experts/archive
https://java.net/projects/faces-bridge-spec/lists/jsr378-observers/archive

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

https://issues.liferay.com/browse/JSR378

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

https://java.net/projects/faces-bridge-spec/downloads





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.

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

https://www.jcp.org/en/jsr/detail?id=344
https://www.jcp.org/en/jsr/detail?id=362
https://www.jcp.org/en/jsr/detail?id=329
http://www.liferay.com/community/liferay-projects/liferay-faces/bridge
https://myfaces.apache.org/portlet-bridge/jsr329tck.html