On Sep 11, 2012, at 10:42 PM, Neil Griffin <neil.griffin(a)liferay.com> wrote:
On Sep 11, 2012, at 4:22 PM, Julien Viet <julien(a)julienviet.com> wrote:
>
> On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>>
>> 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.
Just curious -- how does Weld discover class instances that it is not managing? In other
words, how would it find an instance of Portlet or PortletFilter?
>>
>>> 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 ?
In a servlet based webapp, the JSF Spec does not have any requirements for propagation of
request attributes for redirect-after-post.
I was actually refering to the classic servlet scenario (without redirect-after-post).
The main reason propagation of request attributes is a requirement in
the JSF Portlet Bridge Spec is because facesLifecycle.execute() is executed in the
ACTION_PHASE of the portlet lifecycle, and facesLifecycle.renderResponse() is executed in
the RENDER_PHASE of the portlet lifecycle.
>
>>
>>>
>>>>
>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>