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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>