Hi,
I noticed Bauke already attached the patch for the full feature here:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396
So if anyone wants to take a look at the code and/or try it out, please do
;)
Kind regards,
Arjan Tijms
On Fri, Dec 11, 2015 at 1:19 PM, Josh Juneau <juneau001_at_gmail.com> wrote:
>
> Thanks for all of your work on this...it will be great to have all of the
> functionality of <o:socket> in the standard <f:socket>!
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Thu, Dec 10, 2015 at 7:49 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> Yes, interpret it as ".. agree on me taking over .." :) Currently still
>> work in progress, programmatic CDI management is not funny.
>>
>> Just in case, I made some more changes to OmniFaces socket:
>> - Added "port" attribute which allows explicitly specifying WS server
>> port number (as it's possible that the very same container runs the WS
>> server on a different port than the HTTP server).
>> - Endpoint is now lazily programmatically registered on first usage of
>> o:socket instead than eagerly on startup.
>> - Endpoint now accepts only connections from predefined channel names
>> (the ones specified in o:socket channel attribute), all others will just be
>> aborted by an exception.
>>
>> Cheers, B
>>
>> On Tue, Dec 8, 2015 at 11:09 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Dec 8, 2015 at 8:38 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>>
>>>> Only, it may require an internal JSON encoder or perhaps the javax.json
>>>> API (which is unfortunately not available on servletcontainers like Tomcat
>>>> and Jetty on contrary to WebSockets).
>>>>
>>>
>>> If I understood correctly, JSF 2.3 can depend on pretty much everything
>>> from the Java EE Web Profile, so this shouldn't be a problem by itself. For
>>> Tomcat and friends it would then be a matter of adding the JSON encoder
>>> separately, wouldn't it? That's currently how it works for the CDI and
>>> BeanValidation dependencies.
>>>
>>> Nevertheless, may be nice to see if some explicit pluggability mechanism
>>> can be used here.
>>>
>>> For an initial version in Mojarra it may be an option to omit JSON
>>> first, and then do the JSON support in a second iteration.
>>>
>>>
>>>
>>>> I only wonder if both you and Ed agree on taking over the <o:socket> in
>>>> its current form for JSF 2.3 <f:socket>.
>>>>
>>>
>>> Just to be sure, with "taking over" I guess you mean "agree that the
>>> current approach/design of o:socket is carried over to Mojarra by you",
>>> right? ;)
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>> Among others, I omitted the SSE support as it isn't standardized yet
>>>> while WS is even backed by a Java EE API (JSR356) which is even implemented
>>>> in barebones servletcontainers like Tomcat and Jetty. And, some attributes
>>>> have been reworked to keep it as simple as possible.
>>>>
>>>> Cheers, B
>>>>
>>>>
>>>> On Tue, Dec 8, 2015 at 5:40 PM, manfred riem <manfred.riem_at_oracle.com>
>>>> wrote:
>>>>
>>>>> Hi Bauke,
>>>>>
>>>>> Looks good!
>>>>>
>>>>> How much work would it be to make it all available for the RI?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Kind regards,
>>>>> Manfred Riem
>>>>>
>>>>>
>>>>> On 12/7/15, 1:38 PM, Bauke Scholtz wrote:
>>>>>
>>>>> For the rendered javadoc see also first link in my previous mail:
>>>>> http://omnifaces.org/docs/javadoc/current/org/omnifaces/cdi/push/Socket.html
>>>>> It reads more pretty.
>>>>>
>>>>> Cheers, B
>>>>>
>>>>> On Mon, Dec 7, 2015 at 7:08 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Looks great! I noticed there's a bunch of information about the
>>>>>> working and usage of this in the javadoc of this class:
>>>>>> https://github.com/omnifaces/omnifaces/blob/master/src/main/java/org/omnifaces/cdi/push/Socket.java
>>>>>>
>>>>>> That one may be a good read for the EG specifically.
>>>>>>
>>>>>> Would be great if a version of this can be pushed to the RI before
>>>>>> long. It's been a while since the last commit for a 2.3 feature, and
>>>>>> nothing better to keep the community interested than some actual working
>>>>>> code they can play around with I guess ;)
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 7, 2015 at 10:23 AM, Bauke Scholtz <balusc_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Last weekend I developed and added o:socket for OmniFaces, which
>>>>>>> could be used as base for f:socket:
>>>>>>> http://omnifaces.org/docs/javadoc/current/org/omnifaces/cdi/push/Socket.html
>>>>>>> Source code can be found here:
>>>>>>> https://github.com/omnifaces/omnifaces/tree/master/src/main/java/org/omnifaces/cdi/push
>>>>>>> (4 classes).
>>>>>>>
>>>>>>> Some considerations I took are however differ from f:socket:
>>>>>>>
>>>>>>> - I dropped SSE support. As per http://caniuse.com/#feat=websockets
>>>>>>> vs http://caniuse.com/#feat=eventsource the WS enjoy broader
>>>>>>> support (IE/Edge!) and the protocol is also much more efficient than SSE
>>>>>>> (no persistent open connection). A single protocol also keeps server/client
>>>>>>> side code much simpler.
>>>>>>>
>>>>>>> - I dropped proposed widgetvar/autoconnect attributes and instead
>>>>>>> added enabled attribute. It basically controls whether the underlying WS
>>>>>>> init script will be rendered or not. This is evaluated during view render
>>>>>>> time and can be ajax-updated. The socket can be explicitly closed via a
>>>>>>> public script function taking just channel name.
>>>>>>>
>>>>>>> - I dropped proposed onerror attribute and instead added onclose
>>>>>>> attribute. It will also be invoked during onerror and is more useful as the
>>>>>>> CloseEvent is then available which also contains the error code. The script
>>>>>>> is written that way that it's also invoked when WS is not supported (e.g.
>>>>>>> IE6-9), a custom error code of -1 is then passed.
>>>>>>>
>>>>>>> The combination with o:commandScript (similar component is also
>>>>>>> scheduled for JSF 2.3, see spec issue 613) makes it a very nice tool to
>>>>>>> trigger ajax updates via push.
>>>>>>>
>>>>>>> Cheers, Bauke
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 3, 2015 at 11:01 PM, Edward Burns <
>>>>>>> edward.burns_at_oracle.com> wrote:
>>>>>>>
>>>>>>>> >>>>> On Mon, 24 Aug 2015 05:31:16 -0700, Edward Burns <
>>>>>>>> edward.burns_at_oracle.com> said:
>>>>>>>>
>>>>>>>> EB> Executive Summary: Ed cites discussion thus far and concludes
>>>>>>>> our
>>>>>>>> EB> next step is to answer this question: How does this feature
>>>>>>>> interact
>>>>>>>> EB> with the JSF request processing lifecycle? In Ed's thinking, it
>>>>>>>> EB> does not. Ed asks Cagatay (or anyone else who knows the
>>>>>>>> answer) to
>>>>>>>> EB> explain how this works for PrimeFaces p:socket.
>>>>>>>>
>>>>>>>> I'm having a hard time resolving the sketches people have been
>>>>>>>> sharing
>>>>>>>> here on the list with the examples of <p:socket> from the PrimeFaces
>>>>>>>> showcase. There are seven examples. Let's take the simplest four
>>>>>>>> of
>>>>>>>> them in turn and ask the question, "How does the usage of p:socket
>>>>>>>> interact with the JSF lifecycle?"
>>>>>>>>
>>>>>>>> Counter <http://www.primefaces.org/showcase/push/counter.xhtml>
>>>>>>>>
>>>>>>>> On first render, the count value is taken from the ApplicationScoped
>>>>>>>> GlobalCounterView bean. When the button is pressed, an Ajax
>>>>>>>> postback
>>>>>>>> happens and an actionListener is invoked. The actionListener method
>>>>>>>> causes a publish() on the PrimeFaces EventBus. The listener for
>>>>>>>> this
>>>>>>>> event is synchronously invoked, which returns the count string,
>>>>>>>> which
>>>>>>>> somehow makes its way to the WebSocket endpoint, which sends it
>>>>>>>> down the
>>>>>>>> WebSocket to the clients. At the same time, the JSF lifecycle
>>>>>>>> yields an
>>>>>>>> Ajax response, but the Ajax response does not contain any visible
>>>>>>>> markup. Rather, the WebSocket connection is used to cause the
>>>>>>>> counter
>>>>>>>> to be updated via jQuery on all browsers currently viewing the same
>>>>>>>> page.
>>>>>>>>
>>>>>>>> Conclusion: the <p:socket> does not interact directly with the JSF
>>>>>>>> lifecycle, it just receives the update from the browser. On the
>>>>>>>> other
>>>>>>>> hand, the dispatching of the event that causes the push to the
>>>>>>>> browser
>>>>>>>> *does* happen during the Ajax request postback.
>>>>>>>>
>>>>>>>> ViewParam <
>>>>>>>> http://www.primefaces.org/showcase/push/viewparam.xhtml?data=foo>
>>>>>>>>
>>>>>>>> On first render, the incoming data=foo query parameter is decode
>>>>>>>> into
>>>>>>>> the <f:viewParam>. During updateModelValues, the value is pushed
>>>>>>>> into
>>>>>>>> the EL expression #{viewParamPush.data}. Before Render Response,
>>>>>>>> the
>>>>>>>> prerender() method is called. This causes the a publish on the
>>>>>>>> PrimeFaces EventBus. The listener for this event is synchronously
>>>>>>>> invoked, which returns the data, which somehow makes its way to the
>>>>>>>> WebSocket endpoint, which sends it down the WebSocket to the
>>>>>>>> clients.
>>>>>>>>
>>>>>>>> Conclusion: the <p:socket> does not interact directly with the
>>>>>>>> lifecycle. On the other hand, the decoding of the viewParam does
>>>>>>>> happen
>>>>>>>> during the full GET request.
>>>>>>>>
>>>>>>>> Notify <http://www.primefaces.org/showcase/push/notify.xhtml>
>>>>>>>>
>>>>>>>> On first render, the simple form gets the two values from the
>>>>>>>> request
>>>>>>>> scoped bean NotifyView. When the button is pressed, an Ajax submit
>>>>>>>> happens, and the action listener NotifyView.send() method is called.
>>>>>>>> This causes a publish to the EventBus. Synchronously on the same
>>>>>>>> thread
>>>>>>>> the listener is invoked which uses the JSONEncoder to convert the
>>>>>>>> FacesMessage to JSON, which is sent to the browser.
>>>>>>>>
>>>>>>>> Consclusion: Same pattern as before.
>>>>>>>>
>>>>>>>> Checkin <http://www.primefaces.org/showcase/mobile/checkin.xhtml>
>>>>>>>>
>>>>>>>> This one uses javascript to set the value of some hidden fields
>>>>>>>> using
>>>>>>>> the browser's current position. This is combined with the value of
>>>>>>>> the
>>>>>>>> text field and sent via an Ajax POST. The publish() method is
>>>>>>>> bound as
>>>>>>>> the actionListener of the button, and this causes a publish to the
>>>>>>>> EventBus. From there the listener for the event receives the
>>>>>>>> Checkin
>>>>>>>> pojo, which is sent to the browser as JSON.
>>>>>>>>
>>>>>>>> Conclusion: Same patterns as before.
>>>>>>>>
>>>>>>>> At this point, I think it is pretty clear that the intended usage of
>>>>>>>> <p:socket> is simply to provide a shorthand for opening up a generic
>>>>>>>> connection between the server and the client and that the data sent
>>>>>>>> over
>>>>>>>> that connection does not have anything to do with the request
>>>>>>>> processing
>>>>>>>> lifecycle.
>>>>>>>>
>>>>>>>> So the bottom line for our design of <f:socket> in JSF 2.3 is that
>>>>>>>> it
>>>>>>>> will follow the example of <p:socket> and not necessarily have
>>>>>>>> anything
>>>>>>>> to do with the JSF requets processing lifecycle.
>>>>>>>>
>>>>>>>> Ed
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>>>>>>> | 44 Business days til JavaOne 2015
>>>>>>>> | 59 Business days til DOAG 2015
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>