Andriy, Sadly no. Honestly, this leads to broken apps. Just to clarify my setup:
- WAR File deployed to Tomcat - Has Weld Servlet + CXF CDI + CXF SSE modules deployed - Has no SSE server side components At this point, I may use the client to talk to a remote server (for inter-node communication) but don't rely on it long term. I have no server side components. But you're saying I must set the transportId to SSE. The SSE transportId requirement is not documented anywhere as best as I can tell. SSE isn't listed at http://cxf.apache.org/docs/transports.html for Atmosphere. I think a better approach would be to modify CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault ( https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119 ) so that instead of hard coding the HTTP transport as the default, we ask for the first destination factory it finds registered (if one is). Thoughts? John On Sun, Feb 25, 2018 at 9:25 AM Andriy Redko <drr...@gmail.com> wrote: > I wish it could be as easy as that :) Hope my previous messages give some > context and explanations why we have dedicated transport and why we need > to set Transport Id in a few places, not just one. It would be ideal to > enrich HTTP transport with SSE support but it will take some time, not > an easy one (certainly doable). > > Best Regards, > Andriy Redko > > JDA> I see a bit more when this is failing. > > JDA> When the JAXRS bean has the transport ID set, In > DestinationFactoryManager > JDA> you have two factories created, both for SSE (regular & config > JDA> namespaces). However, since on the servlet the transportId is null > when it > JDA> tries to look up the namespace it defaults to the HTTP transport. > This > JDA> causes it to create a new destination factory where nothing has been > found. > > JDA> So I think what I would recommend is coming up with a way for CXF to > figure > JDA> out a better default, instead of the using the default transportId. > > JDA> Or do as Romain says and make it so that SSE works on the normal > JDA> transportId. > > JDA> John > > JDA> On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > JDA> wrote: > > >> +1 wondered the same and technically sse can just be activated for http > >> transport IMHO > > >> Le 25 févr. 2018 05:10, "John D. Ament" <johndam...@apache.org> 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 <johndam...@apache.org > > > >> > 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 > >> > > > >> > > > >
