Hi,
Nope, doesn't work without CDI. Also doesn't work without JSR 356 (Java API
for WebSocket 1.0). Applications that want to use this new feature should
have both a CDI and a WebSocket implementation present. If they are not
using these yet, they should then start using them. Note that things like
@FlowScoped also doesn't work without CDI.
Perhaps stating the obvious, but note that it's also a JSF 2.3 specific
feature (no backport for JSF 2.2 available). Applications that are not
using JSF 2.3 yet, and want to use the PushContext have to start using JSF
2.3. If they for some reason can't use that, they may find an alternative
in the OmniFaces version (although that, too, requires CDI and WebSocket,
but doesn't require JSF 2.3) or the PrimeFaces version (doesn't require
WebSockets).
Also, the feature (at least in the RI) also requires JDK 8. Applications
that are not using JDK 8 yet have to start using it.
Another thing to consider; JSF 2.3 will not be final for about a year I
guess, so applications have at least a year to upgrade. If they are using
anything else than GlassFish or a separate Mojarra they even have more time.
That said, if you can provide a patch for this that's not too big or
intrusive and that can function as an add-on (backwards compatible jar,
like the Tyrus SPI we introduced recently), then that could certainly be an
option.
Kind regards,
Arjan Tijms
On Mon, Sep 5, 2016 at 2:57 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>