You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2018/02/25 03:59:36 UTC
Handling the case where CXF Servlet doesn't match expected transport ID
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
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
Hey John,
For server-side the Transport Id is required on servlet level to initialize
the proper transport. It is also required when constructing factory beans
to select the transport to use. The reason is because there is no clear way
(at least right now) to get it from servlet. So to answer your question, yes,
sadly we have to have both set and they should match.
It would be great to have a single setting, however the transport has to
be initialized way before any kind of features / factory beans are. This is
the only reason to have both.
For the client-side, there are no changes, the transport doesn't need to be
modified, plain old HTTP.
Thanks.
Best Regards,
Andriy Redko
JDA> Hi,
JDA> So I've finally been able to confirm an issue.
JDA> When CXF's SSE libraries are on the classpath, if the transportId of the
JDA> servlet does not match the transport ID set with the SSE component, then no
JDA> services are discovered.
JDA> IMHO, there may be cases where the SSE libraries are present (client only)
JDA> and no server runtimes are there. In this case, the transport ID will not
JDA> match.
JDA> I'm curious, do both need to be set? What is the benefit/need on the
JDA> servlet layer needing the transport ID set when the underlying feature also
JDA> does it?
JDA> John
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
I would not mix Websockets and SSE. The fact we use Atmospthere for SSE is not related to Websockets anyhow,
but only leverages the Atm capabilities to support SSE as well (and coincidenatally, Websockets, which in context
of SSE are not used). As I said, this is implementation decision we made, it does not mean this is the only one
and ideally, HTTP transport should be enhanced with SSE support.
RMB> Well, SSE works without atmosphere leveraging websocket standard so this would reuse plain http transport and also
RMB> SSE is by design a spec on top of http so shouldn't require another transport by design, no?
RMB> Worse case testing if SSE is here and using it should be enough to not impact users and make it work in all case, no?
RMB> Romain Manni-Bucau
RMB> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
RMB> 2018-02-25 15:50 GMT+01:00 John D. Ament <jo...@apache.org>:
RMB> Andriy,
RMB> Sadly no. Honestly, this leads to broken apps. Just to clarify my setup:
RMB> - WAR File deployed to Tomcat
RMB> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed
RMB> - Has no SSE server side components
RMB> At this point, I may use the client to talk to a remote server (for
RMB> inter-node communication) but don't rely on it long term. I have no server
RMB> side components. But you're saying I must set the transportId to SSE.
RMB> The SSE transportId requirement is not documented anywhere as best as I can
RMB> tell. SSE isn't listed at http://cxf.apache.org/docs/transports.html for
RMB> Atmosphere.
RMB> I think a better approach would be to modify
RMB> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
RMB> https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
RMB> )
RMB> so that instead of hard coding the HTTP transport as the default, we ask
RMB> for the first destination factory it finds registered (if one is).
RMB> Thoughts?
RMB> John
RMB> 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
>> >> > >
>> >> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well, SSE works without atmosphere leveraging websocket standard so this
would reuse plain http transport and also SSE is by design a spec on top of
http so shouldn't require another transport by design, no?
Worse case testing if SSE is here and using it should be enough to not
impact users and make it work in all case, no?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
2018-02-25 15:50 GMT+01:00 John D. Ament <jo...@apache.org>:
> Andriy,
>
> Sadly no. Honestly, this leads to broken apps. Just to clarify my setup:
>
> - WAR File deployed to Tomcat
> - Has Weld Servlet + CXF CDI + CXF SSE modules deployed
> - Has no SSE server side components
>
> At this point, I may use the client to talk to a remote server (for
> inter-node communication) but don't rely on it long term. I have no server
> side components. But you're saying I must set the transportId to SSE.
>
> The SSE transportId requirement is not documented anywhere as best as I can
> tell. SSE isn't listed at http://cxf.apache.org/docs/transports.html for
> Atmosphere.
>
> I think a better approach would be to modify
> CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
> https://github.com/apache/cxf/blob/master/rt/transports/
> http/src/main/java/org/apache/cxf/transport/servlet/
> CXFNonSpringServlet.java#L119
> )
> so that instead of hard coding the HTTP transport as the default, we ask
> for the first destination factory it finds registered (if one is).
>
> Thoughts?
>
> John
>
> 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
> > >> > >
> > >> >
> >
> >
> >
>
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
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 <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
>> >>> >> > >
>> >>> >> >
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by 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
>> >>> >> > >
>> >>> >> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
I created https://issues.apache.org/jira/browse/CXF-7659
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
> >>> >> > >
> >>> >> >
>
>
>
>
>
>
>
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
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
>>> >> > >
>>> >> >
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
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 <jo...@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 <jo...@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 <dr...@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 <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
>>> >> >> > >
>>> >> >> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What would be the cost to just get rid of atmos? (it can make all the
discussion pointless doing this path and makes the compatibility with
containers/environments way wider than using atmos and the setup way easier)
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
2018-02-25 16:54 GMT+01:00 John D. Ament <jo...@apache.org>:
> Actually here's another way.
>
> Create a new property on bus for the default transport ID
> Default it to the HTTP one
> in the SSE extension, override it to SSE.
>
> On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <jo...@apache.org>
> 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 <dr...@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 <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
> >> >> >> > >
> >> >> >> >
> >>
> >>
> >>
> >>
>
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
Actually here's another way.
Create a new property on bus for the default transport ID
Default it to the HTTP one
in the SSE extension, override it to SSE.
On Sun, Feb 25, 2018 at 10:47 AM John D. Ament <jo...@apache.org>
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 <dr...@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 <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
>> >> >> > >
>> >> >> >
>>
>>
>>
>>
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
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 <dr...@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 <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
> >> >> > >
> >> >> >
>
>
>
>
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
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 <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
>> >> > >
>> >> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
Andriy,
Sadly no. Honestly, this leads to broken apps. Just to clarify my setup:
- WAR File deployed to Tomcat
- Has Weld Servlet + CXF CDI + CXF SSE modules deployed
- Has no SSE server side components
At this point, I may use the client to talk to a remote server (for
inter-node communication) but don't rely on it long term. I have no server
side components. But you're saying I must set the transportId to SSE.
The SSE transportId requirement is not documented anywhere as best as I can
tell. SSE isn't listed at http://cxf.apache.org/docs/transports.html for
Atmosphere.
I think a better approach would be to modify
CXFNonSpringServlet.getDestinationRegistryFromBusOrDefault (
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java#L119
)
so that instead of hard coding the HTTP transport as the default, we ask
for the first destination factory it finds registered (if one is).
Thoughts?
John
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
> >> > >
> >> >
>
>
>
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
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 <rm...@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 <jo...@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
>> > >
>> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
I see a bit more when this is failing.
When the JAXRS bean has the transport ID set, In DestinationFactoryManager
you have two factories created, both for SSE (regular & config
namespaces). However, since on the servlet the transportId is null when it
tries to look up the namespace it defaults to the HTTP transport. This
causes it to create a new destination factory where nothing has been found.
So I think what I would recommend is coming up with a way for CXF to figure
out a better default, instead of the using the default transportId.
Or do as Romain says and make it so that SSE works on the normal
transportId.
John
On Sun, Feb 25, 2018 at 3:05 AM Romain Manni-Bucau <rm...@gmail.com>
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 <jo...@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
> > >
> >
>
Re: Handling the case where CXF Servlet doesn't match expected transport ID
Posted by Andriy Redko <dr...@gmail.com>.
Technically - absolutely, the decision we have taken to implement SSE using
Atmostphere led to spin off of the different transport implementation. This
is CXF-specific though, the dilemma we faced at the time was to implement SSE
on top of existing HTTP transport (more efforts / time) or rely on some framework
to speed things up (less effors / time). The 2nd approach was choosen but it
introduced some quirks.
RMB> +1 wondered the same and technically sse can just be activated for http
RMB> transport IMHO
RMB> 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 <jo...@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
>> >
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <jo...@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
> >
>
Re: Handling the case where CXF Servlet doesn't match expected
transport ID
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@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
>