It's a bit tough to estimate (sadly I haven't participated in HTTP transport
implementation), but
it will take some time. Also, as I was looking through Atm code, there are some
subtle tricks which
are applied to different containers / versions. I believe it could be easier
with a baseline for
Jetty / Tomcat / Undertow to be set to the recent releases.
To be fair, at the time we have started with adjusting the HTTP transport to
handle SSE, but at some
point run into issues with the way CXF handles output streams. We could
certaily get back to this
idea, moreover some SSE use cases we cannot handle with Atm at all.
Best Regards,
Andriy Redko
RMB> What would be the cost to just get rid of atmos? (it can make all the
discussion pointless doing this path and
RMB> makes the compatibility with containers/environments way wider than using
atmos and the setup way easier)
RMB> Romain Manni-Bucau
RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
RMB> 2018-02-25 16:54 GMT+01:00 John D. Ament <johndam...@apache.org>:
RMB> Actually here's another way.
RMB> Create a new property on bus for the default transport ID
RMB> Default it to the HTTP one
RMB> in the SSE extension, override it to SSE.
RMB> On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <johndam...@apache.org>
RMB> 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
>>> >> >> > >
>>> >> >> >
