Re: Handling the case where CXF Servlet doesn't match expected transport ID

[Andriy Redko <dr...@gmail.com>]

The documentation has been updated to include SSE transport, https://cwiki.apache.org/confluence/display/CXF20DOC/SSE,
should become available on the main site soon. 

JDA> I created https://issues.apache.org/jira/browse/CXF-7659


JDA> On Sun, Feb 25, 2018 at 11:38 AM Andriy Redko <dr...@gmail.com> 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 <jo...@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 <dr...@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 <dr...@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 <
>>  >>> rmannibucau@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" <jo...@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 <
>> johndament@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
>>  >>> >> > >
>>  >>> >> >