cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [DISCUSS]websocket transport with undertow?
Date Tue, 28 Feb 2017 13:44:24 GMT
Hi Freeman,

yeah, please try your new module idea on the branch and see if you can 
make a JAXRS sys test working with it, but also
try to run a websocket web demo with Tomcat 7 first to confirm it is 
working, then with Tomcat 8 and somehow get it actually running :-), and 
I think if you make it happen then it will also work with Undertow

Thanks, Sergey
On 28/02/17 13:39, Sergey Beryozkin wrote:
> Hi Freeman
> On 28/02/17 13:12, Freeman Fang wrote:
>> Hi Sergey,
>> Thanks for the detailed response.
>> I wanna add websocket transport with undertow because just like jetty,
>> we have http-jetty transport and we have websocket transport with
>> jetty websocket implementation.
> We don't have a web socket transport with a Jetty web socket
> implementation. We have a web socket transport which can use Atmosphere
> and it is is not available - then *delegates* to a Jetty implementation
> if it is available. Please have a look at the code.
> And the most important thing is, this CXF web socket transport makes
> sure that irrespectively of which WebSocket implementation is loaded it
> does the proper formatting of the response and processing of the request
> as per the CXF docs/tests/demos which is what you'd need to duplicate
> somehow otherwise.
>> As we also have http-undertow transport and so have websocket
>> transport with undertow websocket implementation should make sense IMHO.
>> And yeah, the websocket transport with undertow websocket
>> implementation should be just as its counterpart, the websocket
>> transport with jetty websocket implementation do.
>> And yes, undertow implement JSR356, but I’m more looking at the
>> embedded undertow server which can support the websocket, not sure how
>> the JSR356 code can kick in here though.
> If Undertow implements JSR356 then the CXF WebSocket Transport can or
> should be able to load it which is what I was referring to.
> For example, a CXF WebSocket demo works with Tomcat 7 but we do not have
> any Tomcat code in CXF not we use Jetty in that case, see what I mean ?
> If it gets fixed to work in Tomcat 8 then it will also work with
> Undertow JSR356 which I expect to be effectively a wrapper around
> Undertow internal WebSocket code. IMHO it is really worth pursuing.
> Otherwise you'd have something like undertow_websocket which would
> duplicate a fair bit of the existing CXF web socket transport code.
> Think about it please, if we can avoid adding one more module by
> enhancing the existing one and achieving the same result for CXF
> endpoints using WebSocket on top of Undertow then it will be good IMHO...
> You can try and go a new module route and add say a JAXRS Undertow
> WebSocket test by copying one of the existing JAXRS web socket tests
> on a new branch and we can discuss it further - I hope once you end up
> doing it you will see why enhancing the existing Web Socket transport
> may be better :-).
> If we can have the existing transport enhanced to load JSR356s correctly
> then we can get rid of the Jetty delegation code, have only Atmosphere
> linking to Tomcat/Jetty/Netty/Undertow JSR356s...
> Sergey
>> Best Regards
>> -------------
>> Freeman(Yue) Fang
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>> On Feb 28, 2017, at 6:38 PM, Sergey Beryozkin <>
>>> wrote:
>>> Hi Freeman
>>> On 27/02/17 23:44, Freeman Fang wrote:
>>>> Hi Team,
>>>> We have websocket transport in CXF for a while, I wanna know how
>>>> wide is this used by CXF users, if this is widely used, is it
>>>> feasible to also add undertow websocket implementation in CXF?
>>> The existing CXF web socket transport is meant to support JAX-RS
>>> flows over WebSocket given that the JSR356 API is not synchronized to
>>> either JAX-RS or JAX-WS at all. Please check systests/jaxrs
>>> WebSockets tests.
>>> I do not remember Aki trying it with JAXWS but with a bit of the
>>> extra work it will work with JAXWS too.
>>> Aki started documenting it here:
>>> and I recall we were discussing enhancing the transport for it to
>>> load the custom bindings to support SOAP etc
>>> This transport uses Atmosphere if it is available and was tested with
>>> Tomcat 7 and Jetty, Tomcat 8 was problematic due to the issues with
>>> the way JSR356 implementation was picked up. Otherwise, if Jetty is
>>> available, it tries to use the Jetty implementation... This transport
>>> will work side by side with either the HTTP Servlet or Http Jetty
>>> transports.
>>> Users are asking and trying it now and then not sure how widely it is
>>> used but it has to be supported IMHO and enhanced (custom bindings.
>>> etc).
>>> As far as the Undertow WebSocket implementation is concerned, why
>>> would you like to get it into CXF ?
>>> If it can support the JAXRS flows and possibly JAXWS flows the way
>>> the current transport can then why not, but IMHO this should be a
>>> prerequisite, given that CXF transports are here to support JAXWS &
>>> JAXRS.
>>> The other question is, does Undertow implement JSR356 ? If yes then
>>> may be a better idea would be to fix the existing CXF websocket
>>> transport to correctly load JSR356 code, which would make it work
>>> with the Undertow or Tomcat8 etc JSR356 code.
>>> Thanks, Sergey
>>>> Any input is appreciated.
>>>> Thanks!
>>>> -------------
>>>> Freeman(Yue) Fang
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat

Sergey Beryozkin

Talend Community Coders

View raw message