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 <johndam...@apache.org> 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 <drr...@gmail.com> 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 <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 >>> >> > > >>> >> >
