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