I finished f:websocket, see patch in
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396
No unit tests have been added, this will come later. Existing unit tests
run without trouble.
I will commit next week in case no one objects.
Cheers, B
On Mon, Dec 21, 2015 at 5:14 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> FYI: WS init failed in GlassFish/Payara when there's no user-provided
> endpoints. Seems like WS spec isn't crystal clear on this and Tyrus impl
> choosed to not eagerly install the container (works fine on Tomcat and
> Undertow). So I created https://java.net/jira/browse/WEBSOCKET_SPEC-240
> for specifically that part so I can at least advance with Mojarra's
> f:websocket.
>
> For the lazy initialization during runtime, I created another issue
> https://java.net/jira/browse/WEBSOCKET_SPEC-241.
>
> Hopefully they will proceed with fixing 241, then that would make 240
> superfluous.
>
> Cheers, B
>
> On Mon, Dec 21, 2015 at 2:16 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Sounds like a plan then, Kito can you initiate the talks to see if it's
>> possible to start a JSR 356 MR and offer to do the work for at least the
>> fallback?
>>
>> On Mon, Dec 21, 2015 at 1:27 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>
>>> FWIW: I'd definitely love to see the possibility to lazily install WS
>>> endpoint during runtime. This appears to be possible given that it just
>>> works fine in Tomcat and Undertow. Only Tyrus throws an illegal state
>>> exception (because this indeed contradicts WS spec). This would save us
>>> from requiring a context parameter. Just the occurrence of a <f:websocket>
>>> in a JSF page would have been sufficient.
>>>
>>> Cheers, B
>>>
>>> On Sat, Dec 19, 2015 at 5:33 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Fri, Dec 18, 2015 at 10:28 PM, Kito Mann <kito.mann_at_virtua.com>
>>>> wrote:
>>>>
>>>>> FWIW, I strongly believe we should support long polling as an
>>>>> alternative to WebSocket. JSF is used by lots of big companies that may not
>>>>> be able to use WebSocket, and having a reliable fallback is important.
>>>>>
>>>>
>>>> Such compatibility is a bit of a double edged sword. On the one hand
>>>> it's important to keep users on the system and make sure they can upgrade,
>>>> on the other hand it also tends to bloat the platform.
>>>>
>>>> In this case those who can not use WebSocket yet can still use JSF 2.3
>>>> but just for push seek out other alternatives, like the PrimeFaces push.
>>>>
>>>> Also don't forget that Java EE 8 is scheduled for no sooner than ~half
>>>> of 2017, and if history is anything to go by may even be later. A lot of
>>>> vendors take between 1.5 and 2.5 years to implement the new spec (see my
>>>> research here:
>>>> http://arjan-tijms.omnifaces.org/2014/10/java-ee-process-cycles-and-server.html).
>>>> From experience I know companies, especially the bigger ones, take at the
>>>> very minimum some 6 months to switch to a new server. Practically I guess
>>>> this means big companies won't be using JSF 2.3 in production until ~2020,
>>>> and by then WebSocket is hopefully truly ubiquitous.
>>>>
>>>> On the other hand, if you do feel the reliable fallback is absolutely
>>>> important, wouldn't it be better to put this in JSR 356? Such fallback
>>>> could be beneficial for all WebSocket usage, not just for JSF.
>>>>
>>>> Now as Linda et all mentioned at the Java EE list and elsewhere there
>>>> is a resource problem (other constraints on the time of people), but I
>>>> guess that could be largely mitigated if you provided all the necessary
>>>> patches for a solution. Now I can't speak for the JSR 356 lead of course,
>>>> but this typically means a full patch for the RI, a test example on which
>>>> the TCK may be based, and the spec text. Normally Oracle would also have to
>>>> find resources to do a WLS implementation, but that likely won't be needed
>>>> here since WLS already supports a fallback natively.
>>>>
>>>> IMHO, such fallback together with making it legal to instal the WS
>>>> endpoint lazily during runtime would make a great MR. What do you think
>>>> about this option?
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>