I created https://issues.apache.org/jira/browse/CXF-7659
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 > >>> >> > > > >>> >> > > > > > > > >
