On 11 Sep 2012, at 21:08, Neil Griffin wrote:
> Comments inline, with one question for Pete inline as well.
>
> On Sep 11, 2012, at 8:14 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>>
>> On 10 Sep 2012, at 19:58, Julien Viet wrote:
>>
>>> Hi,
>>>
>>> I think that one important issue around this is the fact that Portlet was
never part of Java EE. Back in Portlet 2.0 time, Stefan (the IBM spec lead) discussed with
the Java EE (or J2EE rather) spec lead to work on the inclusion of the portlet container
but nothing came out of it. Therefore the portlet spec defines a component model for
aggregated application, it is designed to interact with the Servlet specification but it
does not have a formal relationship with Jave EE.
>>
>> Agreed, this was an issue that should have added as an open issue.
>
> Perhaps one way around the Java-EE issue, would be to have the CDI Spec define
requirements for portlet support, but to have it be an "optional" feature for
vendors to implement. Portlet support would then be a value-add for Weld.
We don't really do this in the CDI spec today, and the spec is not organised in this
way. i.e. Major PITA ;-)
>
>>> On Sep 7, 2012, at 8:56 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>>>
>>>> All,
>>>>
>>>> I've drafted up the first round of changes. The diff is at
https://github.com/pmuir/cdi/compare/CDI-120 and I've attached a copy of the spec.
Please use them in tandem to understand the changes I've made, if you don't read
docbook ;-)
>>>>
>>>> <cdi-spec.pdf>
>>>>
>>>> I've added a few open issues:
>>>>
>>>> OPEN ISSUE: Should we support injection into portlets and portlet
filters? <-- My understanding is we can't do this without portlet spec changes, but
please comment
>>>
>>> I believe we should, I don't think we need portlet spec changes (I
initially said we should but it is a mistake, please apologize).
>>
>> Ok, let's think about how we specify this. CDI automatically injects
"beans" (which it defines) and "Java EE component classes" (which the
Java EE spec defines, which includes Servlets, filters, EJBs etc - i.e. all the Java EE
non-CDI artifacts you get injection into today).
>
> The portlet container acts as a pseudo-IOC container for managing Singleton instances
of Portlet and PortletFilter, as defined by portlet developers in the WEB-INF/portlet.xml
descriptor.
>
> @Pete: Is it possible for a CDI implementation like Weld would be able to @Inject
into instances that it is not managing?
It is, yes. It's just a case of what we spec vs what is vendor value-add.
> If not, then I have an idea for an alternate mechanism.
>
>>
>>>
>>>> OPEN ISSUE: Where should we specify JSF Portlet Bridge specific rules
about propagating the request context between the action request and render requests?
<-- Ken and I propose these go into the bridge spec
>>>
>>> In Portlet Container, request and action phases are clearly separated and one
should not assume that anything associated with a request could be propagated to other
phases. Usually web framework (built on top of servlet) don't do that unless they
implement the "redirect-after-post" scheme which would break the request into
two phases (action -> redirect -> render).
>>>
>>> The component in charge of coordinating portlet phases is the portal and this
part is not specified, so some portal can perform the two phases in a single request and
some can do in two requests.
>>>
>>> Technically speaking, I think the main issue is that you never have the
guarantee that the render phase will be invoked after the action phase whether it's
managed by the Portlet Container / Portal or by JSF Portlet Bridge. If you have a solution
for propagating the request context between the phases that works if the render phase is
not invoked, then it could even be managed by the Portlet Container.
>>>
>>> The benefit of putting in the Portlet Container is that it would benefit all
frameworks for Portlets and would not be restricted to the Portlet Bridge.
>>
>> I'll let Neil, Mike and Ken comment here on what the Portlet Bridge does
today (it's possible I've misunderstood what they told me).
>
> Although it is not guaranteed, I think that it is safe for CDI to assume that the
RENDER_PHASE of the portlet lifecycle will be invoked 99.999% of the time after the
ACTION_PHASE. As a failsafe, there could be a cleanup mechanism upon session expiration.
>
> The requirement for propagating the request context between the action request and
render requests is something that JSF portlets require, and is currently specified in the
JSF Portlet Bridge spec via propagation of request attributes. Although it would be nice
to have in the Portlet API, it is not always required by plain old Java/JSP portlets.
>
> In order to foster adoption, I think that this is something that Oracle, JBoss, and
Liferay could support directly in our JSF Portlet Bridge implementations, which could
later be formalized by the next JSF Portlet Bridge EG. This is the strategy we all adopted
for JSF 2.0 support.
The idea is to spec this behavior for CDI in the PortletBridge spec anyway, so this seems
sane.
how does it work in a Servlet Container ? does JSF in Servlet manages it or does it
inherits the behavior from the Servlet container ?
>
>>
>>>
>>>> OPEN ISSUE: Where should we specify JSF Portlet Bridge specific rules
about propagating transient conversations between the action request and render requests?
<-- Ken and I propose these go into the bridge spec
>>>
>>> Same as above :-)
>
> With this one too, I'd say let's get it working in our bridge
implementations, and later formalize by the next JSF Portlet Bridge EG.
>
>>>
>>>>
>>>> In your review, please do focus on whether I've used terminology
aligned with the portlet spec, so that we don't end up with ambiguity!
>>>>
>>>> Thanks!
>>>>
>>>> Pete
>>>>
>>>
>>
>