Technically - absolutely, the decision we have taken to implement SSE using Atmostphere led to spin off of the different transport implementation. This is CXF-specific though, the dilemma we faced at the time was to implement SSE on top of existing HTTP transport (more efforts / time) or rely on some framework to speed things up (less effors / time). The 2nd approach was choosen but it introduced some quirks.
RMB> +1 wondered the same and technically sse can just be activated for http RMB> transport IMHO RMB> Le 25 févr. 2018 05:10, "John D. Ament" <[email protected]> a écrit : >> Here's a reproducer app, if anyone else is curious. >> https://github.com/johnament/cxf-demo-reactive-cdi >> If you comment out >> https://github.com/johnament/cxf-demo-reactive-cdi/blob/ >> master/src/main/webapp/WEB-INF/web.xml#L10-L13 >> then >> you'll see the issue, but deploying this as is to tomcat will work just >> fine. >> On Sat, Feb 24, 2018 at 10:59 PM John D. Ament <[email protected]> >> wrote: >> > Hi, >> > >> > So I've finally been able to confirm an issue. >> > >> > When CXF's SSE libraries are on the classpath, if the transportId of the >> > servlet does not match the transport ID set with the SSE component, then >> no >> > services are discovered. >> > >> > IMHO, there may be cases where the SSE libraries are present (client >> only) >> > and no server runtimes are there. In this case, the transport ID will >> not >> > match. >> > >> > I'm curious, do both need to be set? What is the benefit/need on the >> > servlet layer needing the transport ID set when the underlying feature >> also >> > does it? >> > >> > John >> >
