Thanks, submitted https://github.com/apache/cxf/pull/386 to address it.
JDA> I created https://issues.apache.org/jira/browse/CXF-7659 JDA> On Sun, Feb 25, 2018 at 11:38 AM Andriy Redko <[email protected]> wrote: >> Sounds reasonable, would you mind to create a ticket? I could pick it up >> shortly (or if you have time, please go ahead). Thanks. >> JDA> Actually here's another way. >> JDA> Create a new property on bus for the default transport ID >> JDA> Default it to the HTTP one >> JDA> in the SSE extension, override it to SSE. >> JDA> On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <[email protected]> >> wrote: >> JDA> Basically, yes. >> JDA> So here's what I'm thinking. >> JDA> - Determine that transportId is null >> JDA> - ask for the registered HTTP one ending with /configuration >> JDA> - If that's null, loop through all registered and return the first >> one ending with /configuration >> JDA> Thoughts? >> JDA> On Sun, Feb 25, 2018 at 10:44 AM Andriy Redko <[email protected]> >> wrote: >> JDA> Hey John, >> JDA> You mean add the capability to DestinationFactoryManager to list all >> registered >> JDA> destination factories and in case transport id is not set, just pick >> the first >> JDA> one? We could try it out, may be we could also give a preference to >> HTTP transport >> JDA> in case more than one is available (at least to minimize the effect >> of the change). >> JDA> Also, the documentation should be updated to reflect the SSE >> transport presence, I >> JDA> will do that shortly. Thanks for spotting it. >> JDA> Makes sense? >> JDA> Best Regards, >> JDA> 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 <[email protected]> >> 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 < >> >>> [email protected]> >> >>> 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" <[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 >> >>> >> > > >> >>> >> >
