In addition, the JSONP API (javax.json.*) is also required for f:websocket.
Cheers, B
On Mon, Sep 5, 2016 at 4:05 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>