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