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