Does PushContext work without CDI? If so, I think we need it. There are
still some apps out there that don't use CDI yet.
___
Kito D. Mann | @kito99 | Author, JSF in Action
Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training and
consulting
Virtua, Inc. | virtua.tech
JSFCentral.com | @jsfcentral | knowesis.io
<
http://knowesis.io/web/webcomponents> - fresh Web Components info
+1 203-998-0403
* Listen to the Enterprise Java Newscast: *http://
<
http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<
http://ww.enterprisejavanews.com>*
On Fri, Sep 2, 2016 at 11:44 AM, Josh Juneau <juneau001_at_gmail.com> wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>