Actually here's another way. Create a new property on bus for the default transport ID Default it to the HTTP one in the SSE extension, override it to SSE.
On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <johndam...@apache.org> wrote: > Basically, yes. > > So here's what I'm thinking. > > - Determine that transportId is null > - ask for the registered HTTP one ending with /configuration > - If that's null, loop through all registered and return the first one > ending with /configuration > > Thoughts? > > > On Sun, Feb 25, 2018 at 10:44 AM Andriy Redko <drr...@gmail.com> wrote: > >> Hey John, >> >> You mean add the capability to DestinationFactoryManager to list all >> registered >> destination factories and in case transport id is not set, just pick the >> first >> one? We could try it out, may be we could also give a preference to HTTP >> transport >> in case more than one is available (at least to minimize the effect of >> the change). >> >> Also, the documentation should be updated to reflect the SSE transport >> presence, I >> will do that shortly. Thanks for spotting it. >> >> Makes sense? >> >> Best Regards, >> Andriy Redko >> >> JDA> Andriy, >> >> JDA> Sadly no. Honestly, this leads to broken apps. Just to clarify my >> setup: >> >> JDA> - WAR File deployed to Tomcat >> JDA> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed >> JDA> - Has no SSE server side components >> >> JDA> At this point, I may use the client to talk to a remote server (for >> JDA> inter-node communication) but don't rely on it long term. I have no >> server >> JDA> side components. But you're saying I must set the transportId to >> SSE. >> >> JDA> The SSE transportId requirement is not documented anywhere as best >> as I can >> JDA> tell. SSE isn't listed at >> http://cxf.apache.org/docs/transports.html for >> JDA> Atmosphere. >> >> JDA> I think a better approach would be to modify >> JDA> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault ( >> JDA> >> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119 >> JDA> ) >> JDA> so that instead of hard coding the HTTP transport as the default, we >> ask >> JDA> for the first destination factory it finds registered (if one is). >> >> JDA> Thoughts? >> >> JDA> John >> >> JDA> 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 >> >> >> > > >> >> >> > >> >> >> >>
