Hi Neil,
Great to hear!
Can you please write up a blog entry that talks about this as people
that want to run it on a plain old Tomcat will have to do the steps
similar to what you do.
Thanks!
Manfred
On 10/16/14, 5:48 PM, Neil Griffin wrote:
> Hi Arjan,
>
> Pleased to e-meet you, and sorry for the delay in responding.
>
> The reason for the delay was because I decided to actually kick the
> tires and try @Inject FacesContext in a JSF portlet with
> Mojarra-2.3.0-m01-SNAPSHOT.
>
> My test environment required that I make Weld and Mojarra compatible
> with plain Tomcat+Pluto which took a few days. But I am happy to
> report that @Inject FacesContext works! (more details below).
>
> On Sep 25, 2014, at 5:56 PM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
>> Hi,
>>
>> On Thu, Sep 25, 2014 at 6:58 PM, Neil Griffin
>> <neil.griffin_at_portletfaces.org
>> <mailto:neil.griffin_at_portletfaces.org>> wrote:
>>
>> The JSF Portlet Bridge will make beans annotated with
>> javax.faces.bean.RequestScoped survive from the ACTION_PHASE to
>> the RENDER_PHASE.
>>
>> But CDI does not do that. If a JSF portlet developer annotates a
>> bean with javax.enterprise.context.RequestScoped, then CDI
>> creates a new bean in both the ACTION_PHASE and RENDER_PHASE.
>>
>>
>> I have to admit I know almost nothing about Portlets, but if I
>> understand correctly this is thus a general problem
>> with javax.enterprise.context.RequestScoped and Portlets, and not
>> specifically with injecting a request scoped FacesContext, right?
>
> Actually it is not considered to be a problem
> with javax.enterprise.context.RequestScoped and *plain* Java Portlets.
> It's just the way things worked out since CDI was developed
> (primarily) with webapps in mind.
>
> It's only a problem with javax.enterprise.context.RequestScoped and
> JSF portlets, when the portlet developer makes the assumption that it
> behaves the same way as javax.faces.bean.RequestScoped.
>
>>
>> But in this case would it really matter? If a single CDI request
>> scope does not survive beyond the Portlet action phase and into the
>> render phase, then there would simply be one additional call to
>> FacesContext#getCurrentInstance if the proxy is referenced again in
>> the render phase, right? This then grabs the current FacesContext
>> according to the existing JSF rules and all should be right again. Or
>> am I missing something obvious?
>
> My tests indicate that you are 100% correct. When the proxy is
> referenced again in the RENDER_PHASE, the
> FacesContextProducer.create(CreationalContext) method is invoked and
> all is well.
>
>>
>> If there is a successor to JSR 329, then one of the requirements
>> for that new JSR *might* be to re-define the behavior
>> of javax.enterprise.context.RequestScoped.
>>
>>
>> Just wondering, but isn't JSR 329 specifically designed for
>> interoperability with JSF 1.2 only?
>
> Although JSR 329 was designed for interoperability with JSF 1.2, 99%
> of the spec requirements and TCK tests apply equally well to JSF 2.x
> bridges. The spec requires that
> <managed-bean-scope>request</managed-bean-scope> exist from the
> ACTION_PHASE to the RENDER_PHASE.
>
>
> Best Regards,
>
> Neil
>
>>
>> On Sep 25, 2014, at 12:36 PM, Leonardo Uribe
>> <leonardo.uribe_at_irian.at <mailto:leonardo.uribe_at_irian.at>> wrote:
>>
>>> Hi
>>>
>>> I know that the trick using @RequestScoped works, but
>>> Is there a 1-1 relationship between FacesContext lifecycle
>>> and the request lifecycle? That works fine on servlets but
>>> it doesn't on portlets (action request / render request).
>>>
>>> It is possible to imagine other scenarios where this
>>> assumption just fail. In my opinion, we should take the
>>> long route, create a CDI scope and use that scope to
>>> store the producer, so it get the right instance. After all
>>> JSF should be in control of FacesContext lifecycle.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2014-09-25 11:02 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com
>>> <mailto:arjan.tijms_at_gmail.com>>:
>>>> Hi,
>>>>
>>>> On Thu, Sep 25, 2014 at 4:32 PM, Edward Burns
>>>> <edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com>> wrote:
>>>>> Arjan, can you take the action item to investigate this and
>>>>> report back
>>>>> to the group? Such investigations and reports are the bread
>>>>> and butter
>>>>> of expert group membership and really add significant value
>>>>> because the
>>>>> results the produce are so actionable.
>>>>
>>>> I took a quick look, and the results are rather interesting.
>>>>
>>>> First of all, the feature is described here:
>>>> http://docs.jboss.org/seam/3/servlet/latest/reference/en-US/html/injectablerefs.html#injectablerefs.http_servlet_request
>>>>
>>>> The producer was created by CDI wizards Dan Allen and Nicklas
>>>> Karlsson, and for the HttpServletRequest it looks as follows:
>>>>
>>>> @Produces
>>>> @Typed(HttpServletRequest.class)
>>>> @RequestScoped
>>>> protected HttpServletRequest getHttpServletRequest() {
>>>> return holder.getHttpServletRequest();
>>>> }
>>>>
>>>> See:
>>>> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam.servlet/seam-servlet/3.1.0.Beta2/org/jboss/seam/servlet/http/ImplicitHttpServletObjectsProducer.java?av=f
>>>>
>>>> The holder is an application scoped bean, which has as its main
>>>> goal
>>>> to collect and hold on to among others the HttpServletRequest via a
>>>> thread local. Collection happens via a CDI event and the listeners
>>>> stores the request object into TLS via a wrapper. Abbreviated it's:
>>>>
>>>> protected void requestInitialized(@Observes @Initialized final
>>>> InternalServletRequestEvent e) {
>>>> ServletRequest req = e.getServletRequest();
>>>> // code omitted
>>>> requestCtx.set(new HttpServletRequestContext(req));
>>>> }
>>>>
>>>> See:
>>>> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam.servlet/seam-servlet/3.1.0.Beta2/org/jboss/seam/servlet/event/ImplicitServletObjectsHolder.java#70
>>>>
>>>> But the wrapper doesn't play a role in injection, since when the
>>>> producer asks the holder for the request instance, it's unwrapped
>>>> again. Abbreviated it's:
>>>>
>>>> public HttpServletRequest getHttpServletRequest() {
>>>> // code omitted
>>>> return
>>>> HttpServletRequestContext.class.cast(requestCtx.get()).getRequest();
>>>> }
>>>>
>>>> See:
>>>> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam.servlet/seam-servlet/3.1.0.Beta2/org/jboss/seam/servlet/event/ImplicitServletObjectsHolder.java#128
>>>>
>>>> So there's not a lot of magic going at all. The key seems to be
>>>> that
>>>> the producer itself is @RequestScoped, but the instance it produces
>>>> doesn't seem to be a request scoped wrapper bean at all, just the
>>>> normal instance. I do wonder a bit why they choose TLS storage
>>>> instead
>>>> of a request scoped bean, but that's beside the issue here.
>>>>
>>>> As JSF already stores the FacesContext in TLS, the entire holder
>>>> construct isn't needed and seemingly the producer would only
>>>> need to
>>>> be annotated with @RequestScoped.
>>>>
>>>> Kind regards,
>>>> Arjan
>>
>>
>