On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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 >>>>> >>>> >>> >> >

On Sep 11, 2012, at 10:42 PM, Neil Griffin <neil.griffin(a)liferay.com&gt; wrote: > > On Sep 11, 2012, at 4:22 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: > >> >> On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >

On Sep 11, 2012, at 10:56 PM, Neil Griffin <neil.griffin(a)liferay.com&gt; wrote: > On Sep 11, 2012, at 4:45 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: > >> >> On Sep 11, 2012, at 10:42 PM, Neil Griffin <neil.griffin(a)liferay.com&gt; wrote: >> >>> >>> On Sep 11, 2012, at 4:22 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: >>> >>>> >>>> On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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). > > Maybe you could rephrase the question? Is the question related to propagation of request attributes? I think that I am a bit confused about what you call exactly "request context" . Are you refering to request attributes or more than that ? I am here thinking about @RequestScope CDI objects (I am not certain they have to be stored as request attributes).

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

On 11 Sep 2012, at 21:42, Neil Griffin wrote: > > On Sep 11, 2012, at 4:22 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: > >> >> On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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? Normally through a Weld specific SPI, that queries the underlying Java EE container (e.g. JBoss AS, GlassFish, whatever). Sometimes there is a specified API/SPI, but it's vanishingly rare. There are a very few: * Validator, ValidatorFactory (BV) can be looked up in JNDI * UserTransaction can be looked up in JNDI (but TransactionManager can't) * Principal can be got hold of somehow IIRC * installing servlet stuff (via web fragments) that do work, but the majority don't: * what EJBs are in the app * what classes are in the app etc. > >>> >>>> 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. > > 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >

On 11 Sep 2012, at 21:22, Julien Viet wrote: > > On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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 ? In Servlet we don't this separation between render and action phases, this seems to be a purely portlet thing. Nor does JSF. If you use redirect-after-post, you get two separate request contexts. JSF supports a "page context" (I think this is the name, this is what we called it in Seam ;-) that will bridge the two requests automatically. But you still get two request contexts. DeltaSpike (CDI extensions) will provide a CDI managed context for the page context (IOW @PageContext backed by the JSF page context). Generally, in CDI 1.1, we don't have any JSF-special support, everything is specified for Servlet (except for automatic propagation of the conversation through certain types of JSF request, but that is really something of a side issue). > > > >> >>> >>>> >>>>> >>>>>> 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 >>>>>> >>>>> >>>> >>> >> >

On 12 Sep 2012, at 06:39, Julien Viet wrote: > several things come to my mind: > > 1/ in practice : a portlet is invoked via a servlet that is itself invoked from the portal servlet via a cross context (between wars) request dispatch . There could be conflicts between an existing context of the underlying servlets and something defined in addition for portlet or bridge. This is an implementation issue, AIUI from discussions there is no requirement that portlets are built on top of servlets, this is just how most are implemented. Therefore we can specify complete behavior for a portlet request, and leave it to an implementation to deal with conflicts such as the ones you describe. > > 2/ Invoking things in a single phase does not provide guarantee on the threading model used by the portal to invoke the action/event/render phase (yes there is also a render phase :-) ) . Here is a global picture of an entire portal request : http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles... . From there several things come to my mind: > > a) if a single thread is used : the request context will be propagated between the action and all the subsequent phases of *all* the portlets involved in the request (usually on the same page). My draft specifies that the request context must be destroyed at the end of each phase of the portlet request, therefore the context must not span the whole portlet request, regardless of threading semantics/ > > b) several threads can be used to process things in parallel for improving performances (one thread perfoms action and then N thread performs render in parallel) : in that situation there are no guarantees that the same thread would be used between action and render phase of the same portlet. My draft specifies that the request context must be active during a render, in respect of the thread processing the render, so I don't think there is an issue here. > > c) so if the bridge maintains a context (whatever it is) between action and render phases that is bound to the thread model (i.e via a thread local) then this will certainly be an issue per a) or b). We probably need a new SPI to handle this. Let's add this as an open issue. > > Let me know if this makes sense to you or not and if there are issues we need to specify to make the model works equally well accross portal/portletcontainer supporting CDI. > > On Sep 12, 2012, at 12:15 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >> >> On 11 Sep 2012, at 21:22, Julien Viet wrote: >> >>> >>> On Sep 11, 2012, at 10:12 PM, Pete Muir <pmuir(a)redhat.com&gt; 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&gt; 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&gt; 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 ? >> >> In Servlet we don't this separation between render and action phases, this seems to be a purely portlet thing. Nor does JSF. >> >> If you use redirect-after-post, you get two separate request contexts. JSF supports a "page context" (I think this is the name, this is what we called it in Seam ;-) that will bridge the two requests automatically. But you still get two request contexts. DeltaSpike (CDI extensions) will provide a CDI managed context for the page context (IOW @PageContext backed by the JSF page context). >> >> Generally, in CDI 1.1, we don't have any JSF-special support, everything is specified for Servlet (except for automatic propagation of the conversation through certain types of JSF request, but that is really something of a side issue). >> >>> >>> >>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

I talked to Neil Griffin (Liferay) and Mike Freedman (Oracle) at JavaOne, and subsequently Ken Finnigan (Red Hat), as well as Bill Shannon (Oracle, Java EE spec lead) about how to move this issue forward. We came to the conclusion that the CDI spec is not the right place to describe portlet support, and that this would be much better done in the Portlet and Portlet Bridge specifications. As we don't have revisions of those planned, we agreed that for now we would write up the support as a wiki page that vendors can optionally agree to support. I've added https://github.com/jboss/cdi/wiki/CDI-Portlet-integration to the CDI wiki, which basically takes all of the changes I proposed for the spec, and makes them into a standalone doc. Neil/Ken, I think we now need to add the JSF specific stuff we discussed previously to this doc. Are you able to do this? If so, the best way is to clone https://github.com/jboss/cdi/wiki/CDI-Portlet-integration (the doc is in markdown) and then you can send a pull request to the wiki, and we can review in the usual way.