You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by michael freedman <mi...@oracle.com> on 2009/01/15 23:39:45 UTC
Apache Software Foundation as "Supporter" of a JSR to define the
Portlet 2.0 Bridge for JavaServer Faces 1.2?
Folks,
I am the spec lead for JSR 301: the Portlet Bridge specification for
JavaServer Faces 1.2. The RI work for this JSR is being done at Apache
in the PortletBridge subproject within MyFaces. For the past year I
have been working under the assumption that I could produce both the
Portlet 1.0 Bridge for JavaServer Faces 1.2 specification and the
Portlet 2.0 Bridge for JavaServer Faces 1.2 under this single JSR. This
assumption had been vetted by the JCP. Unfortunately they misunderstood
the methodology I planned to use which called for separate release dates
of the specifications. They now tell me I need a new JSR to address
this second specification. As I have an already prepared Early (Public)
Draft and a corresponding implementation we are in the process of
releasing an alpha version of in the Apache PortletBridge subproject, I
would like to get this JSR kicked off/started as quickly as possible to
avoid delays down the line. I have attached the new JSR proposal. This
is a more targeted version of the original 301 proposal. The next step
before submitting to the JCP is to get a list of companies/individuals
that "support" this JSR so I can list them with the proposal. The Apache
Software Foundation was listed in the original proposal and as we are
doing the impl here hope I can list it again. Can you let me know
(asap) whether I can include the Apache Software Foundation as a supporter?
-Mike-
Re: Apache Software Foundation as "Supporter" of a JSR to define
the Portlet 2.0 Bridge for JavaServer Faces 1.2?
Posted by Scott O'Bryan <da...@gmail.com>.
I would encourage Apache to support this JSR proposal as well.
I'm not an Apache Member, but I am a PMC for the MyFaces project and the
project lead for the MyFaces Portlet Bridge. With JSR-301 Oracle has
proven quite effectively that they can work with the open process and
with Apache in general. They even worked with the JCP to modify the
license on the JSR-301proposed final draft to remove the "terms of use"
clause at the request of Apache.
Also, the MyFaces Portlet Bridge project has already started work on the
implementation of the Portlet 2.0 bridge and it would be nice for Apache
to show their support for the bridge projects going forward. :)
Just my 2 cents.
Scott
michael freedman wrote:
> Folks,
> I am the spec lead for JSR 301: the Portlet Bridge specification for
> JavaServer Faces 1.2. The RI work for this JSR is being done at
> Apache in the PortletBridge subproject within MyFaces. For the past
> year I have been working under the assumption that I could produce
> both the Portlet 1.0 Bridge for JavaServer Faces 1.2 specification and
> the Portlet 2.0 Bridge for JavaServer Faces 1.2 under this single
> JSR. This assumption had been vetted by the JCP. Unfortunately they
> misunderstood the methodology I planned to use which called for
> separate release dates of the specifications. They now tell me I need
> a new JSR to address this second specification. As I have an already
> prepared Early (Public) Draft and a corresponding implementation we
> are in the process of releasing an alpha version of in the Apache
> PortletBridge subproject, I would like to get this JSR kicked
> off/started as quickly as possible to avoid delays down the line. I
> have attached the new JSR proposal. This is a more targeted version
> of the original 301 proposal. The next step before submitting to the
> JCP is to get a list of companies/individuals that "support" this JSR
> so I can list them with the proposal. The Apache Software Foundation
> was listed in the original proposal and as we are doing the impl here
> hope I can list it again. Can you let me know (asap) whether I can
> include the Apache Software Foundation as a supporter?
> -Mike-
>
> ------------------------------------------------------------------------
>
>
> Title: Portlet 2.0 Bridge for JavaServer Faces 1.2 Specification
>
>
> Summary:
>
> The Portlet 2.0 Bridge defines the semantics of a JSR 286 portlet that
> proxies for JSF 1.2 artifacts.
>
>
> Section 1: Identification
>
> Submitting Member: Oracle Corporation
> Name of Contact Person: Don Deustch
> E-Mail Address: donald.deutsch@oracle.com
> Telephone Number: 650-506-2275
> Fax Number:
>
> Name of Specification Lead: Michael Freedman
> E-Mail Address: michael.freedman@oracle.com
> Telephone Number: 650-506-4904
> Fax Number:
>
>
> Initial Group Membership [list]
>
> Supporting this JSR [list]:
>
>
>
> Section 2: Request
>
>
> 2.1 Describe 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?
>
> 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.
>
>
> 2.4 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 Summarize 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?
>
> javax.portlet.faces package name will be used for API specifications.
>
>
> 2.9 Are there any dependencies on OS, I/O, CPUs?
>
> No.
>
>
> 2.10 Are there any security issues that can't be addressed by
> the existing security model?
>
> No.
>
>
> 2.11 Are there internationalization/localization issues?
>
> No.
>
>
> 2.12 Are there any existing specifications that might become
> obsolete, depracted, or need revision as a result of this work?
>
> No.
>
>
> 2.13 Please describe the anticipated schedule 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:
>
> 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 be 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.16 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.
>
>
> Section 3: Contributions
>
>
> 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) <http://www.jcp.org/en/jsr/detail?id=301>
>
> JSR 268: Java Portlet Specification 2.0
> <http://www.jcp.org/en/jsr/detail?id=286>
>
> JSR 252: JavaServer Faces Specification 1.2
> <http://www.jcp.org/en/jsr/detail?id=252>
>
>
> 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
> <http://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_2.0.x>
>
>
> Section 4: Additional Information
>
>
>
>
>
>
>
>
>
>
>
>
>
>