Coming back to JSONP, it's only required by the Mojarra impl, not by the
2.3 spec.
Cheers, B
On Tue, Sep 6, 2016, 03:29 Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> Hi
>
> BS>> I reimplemented FacesContext#getPushContext() locally and
> BS>> now I recall fragments of why I removed it afterwards. I guess
> BS>> it was due to the somewhat unnatural API. The PushContext
> BS>> is also available when when FacesContext is not available
> BS>> such as when an asynchronous EJB method callbacks a
> BS>> managed bean method in order to send out a push message.
> BS>> And, creating the PushContext requires a "channel name"
> BS>> argument, which means the API looks like
> BS>> facesContext.getPushContext("channelName").
>
> I see. I agree it has sense. It should be possible to do the push
> through PushContext.send(...) from an internal component outside
> JSF control like a EJB bean. So, this feature should be more
> "CDI centric" to align better these use cases. Otherwise, the user
> could be forced to create a FacesContext instance from
> ServletContext and that's not nice.
>
> In that sense, it is not necessary FacesContext.getPushContext(...)
>
> BS>> In addition, the JSONP API (javax.json.*) is also required for
> f:websocket.
>
> Thanks for mention it. I'll keep it in mind.
>
> regards,
>
> Leonardo Uribe
>
>
> 2016-09-05 12:23 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>
>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>