Hi Everyone-
It seems like adding the getPushContext() method to FacesContext may just
confuse users. They may wonder why it is there, if the better choice is to
inject via @Push.
Unless there is a compelling reason to add it to FacesContext, I would
think that the original implementation would suffice, and it makes things
less confusing for the users.
Hope this helps...thanks for all you do.
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Fri, Sep 2, 2016 at 4:20 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> Hi,
>
> I reimplemented FacesContext#getPushContext() locally and now I recall
> fragments of why I removed it afterwards. I guess it was due to the
> somewhat unnatural API. The PushContext is also available when when
> FacesContext is not available such as when an asynchronous EJB method
> callbacks a managed bean method in order to send out a push message. And,
> creating the PushContext requires a "channel name" argument, which means
> the API looks like facesContext.getPushContext("channelName").
>
> At least, it doesn't block any unit tests.
>
> If there are no objections, I will create a new spec issue to add below
> method to FacesContext:
>
> /**
> * <p class="changed_added_2_3">Return the {_at_link PushContext}
> instance associated with given push channel name.
> * Due to the asynchronous nature of push, it is strongly recommended
> inject it via <code>@</code>{_at_link Push}
> * as the {_at_link FacesContext} is not necessarily available at the
> moment the push message needs to be sent.</p>
> *
> * @param channel The name of the push channel.
> * @return Instance of <code>PushContext</code> associated with given
> push channel name.
> */
> public abstract PushContext getPushContext(String channel);
>
>
> Cheers, B
>
>
> On Fri, Sep 2, 2016 at 3:45 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> Hi
>>
>> Ok, now I understand. Thanks for the clarifications.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2016-09-01 16:47 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>>
>>> Hi,
>>>
>>> On Thu, Sep 1, 2016 at 5:59 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>>> wrote:
>>>
>>>> My reasoning is in JSF there is always a way to do certain things
>>>> programmatically.
>>>>
>>>
>>> This often can be done with the CDI APIs just as well. The entry point
>>> is CDI.current().select(SomeBean.class, ...);
>>>
>>> Basically, if it can be injected it can typically be obtained that way.
>>>
>>>
>>>> For example Application.evaluateExpressionGet(...) to get beans using
>>>> EL, but some new features seem to work only with CDI or maybe rely too much
>>>> on it.
>>>>
>>>
>>> Some features indeed work with CDI only, but the Java EE platform and
>>> JSF among it has been moving towards that already in EE 7. @FlowScoped is a
>>> CDI only feature as well, as is @Transactional in JTA. MVC and the Security
>>> API are fully CDI based to begin with.
>>>
>>>
>>>
>>>> The annotation syntax using @Inject and @Push is nice, but I'm
>>>> suspicious about why PushContext extends Serializable. I don't understand
>>>> why extends from this interface, or if this is necessary.
>>>>
>>>
>>> In order to inject into a beans with a passivating scope, the injection
>>> target has to Serializable.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>
>>>
>>
>