[jsr-314-open] Pre-JCP filed draft of JSF 2.2 JSR

[Michael Freedman]

Speaking as the spec lead of the Portlet Bridge ... my take on this  
.... inline.

On 2/17/2011 1:20 PM, Ed Burns wrote:
>>>>>> On Wed, 16 Feb 2011 11:58:56 -0500, Stephen Kenna<kenna at us.ibm.com>  said:
> SK>  Just looking for a quick clarification on the following statement:
> SK>  Make the composite component feature usable so a "component server" can be
> SK>  included in a portlet runtime such that portlets can use the components in
> SK>  context-dependent ways. This feature is known as "remote components" in
> SK>  the portlet community.
>
> SK>  Is 'remote components' referring to WSRP?
>
> No, this is a new idea that was kicking around from the time we
> developed the composite component feature and Mike Freedman from the
> Portlet spec suggested something very similar.  Considering that a
> composite component declares its interface and impl in markup, it's
> possible to allow your deployed composite component library to be served
> up in response to simple get requests.

My answer would be yes and no.  What I am hoping is designed is support 
for composite component implementations that are independent from their 
declaration.  Furthermore, I am hoping that such a design allows such 
implementations to be remote from the web application using them (it).  
Lastly, I am hoping that such a design has the flexibility that allows 
for differing remote provider implementations/platforms to be used to 
satisfy/proxy/bind remote composite components.  Yes, as Ed indicates 
above one such provider might be based on REST.  But this is where I 
answer yes to your question, I for one intend to work hard at supporting 
a provider based on the portlet technologies.  So, yes, in such a case 
when the composite component is truly remote, WSRP would be the 
underlying protocol used for communication.

> SK>  Also, do we need to open a new JSR for a JSF 2.x Portlet Bridge?  I see
> SK>  you have referred to the existing JSR 329 which was written for JSF 1.2.
>
> Personally, I think we do need to open up such a JSR, and having IBM's
> support for such a JSR would be very helpful.  However, what *I'm*
> trying to establish is support for a new JSR for JSF.  A portlet JSR is
> another matter entirely.

Opening a JSR for the Portlet 2.0 Bridge for JSF 2.0 is currently being 
looked at.  However, as JSF 2.0 has already been out for some time, its 
currently felt we would better support the community by publishing a 
stable, working implementation of such a bridge based on logical 
extensions/migration of JSR 329 before getting into the thick of the JSR 
process which tends to be more methodical.  To that end there is now a 
3.0.x Trunk in svn of the Apache MyFaces PortletBridge project (where 
the JSR RI work is): 
https://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk_3.0.x 
.  This code is stable enough for an alpha release in that it passes the 
upgraded version of the 329 TCK and runs the various Ajax and 
CompositeComponent samples I could find on the web/in Mojarra.  I will 
be doing an official (alpha) release shortly once I have clearance.  But 
in the meantime, interested parties can build/use it directly from this 
repository.  FYI ... anyone wanting to do so may want to contact me as I 
have found bugs in both Mojarra and MyFaces that prevent proper 
execution in a portlet environment.  I can suggest/provide various 
patches to get around these problems.

Finally, since the question was asked here -- when proposed the Bridge 
JSR a few years ago there was a discussion on whether it needed to be 
separated from JSF or not.  At the time we argued that it should be 
because the nuances of the portlet environment needed the focus of that 
community more than the JSF community.  Now that the core of the bridge 
have been defined, standardized, and proven to work in practice, its 
useful to revisit this question.  Given that the underlying portlet spec 
is both stable and unlikely to change in the near or medium future, it 
seems that the bridge is now pretty much only tied to future JSF 
enhancements.  Is it time to tie this work closer to the JSF standards 
work?  If so, what form do you think this should take?
     -Mike-

> Ed
>