You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Freeman Fang <fr...@gmail.com> on 2017/02/27 23:44:20 UTC
[DISCUSS]websocket transport with undertow?
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?
Any input is appreciated.
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Re: [DISCUSS]websocket transport with undertow?
Posted by Freeman Fang <fr...@gmail.com>.
Thanks Sergey!
Merged to the master.
Cheers
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Apr 20, 2017, at 7:41 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hi Freeman
>
> Thanks, looks like it is all very much consistent with the way either Servlet (JSR356) or Container-specific (Jetty and now Undertow) WebSocket support is activated, nice work
>
> Thanks, Sergey
> On 20/04/17 07:18, Freeman Fang wrote:
>> Hi Sergey,
>>
>> I just pushed my commit to websocket-undertow branch.
>>
>> The main purpose is for the standalone CXF endpoint(not CXF endpoint deployed into servlet container, as the AtmosphereWebSocketServletDestination should work with all servlet container implementing JSR365 now), using AtmosphereWebSocketUndertowDestination or UndertowWebSocketDestination when jetty isn’t available on the class path. The original AtmosphereWebSocketJettyDestination still use jetty to handle the transport level stuff like read request and send response. Now in the WebSocketDestinationFactory I check if the jetty is available, keep things work as is, but if there’s no jetty on the class path but instead undertow available, use the undertow counterpart ones. The logic here is quiet similar as before, when Atmosphere is available, use AtmosphereWebSocketXXXXDestination, if there’s no Atmosphere, just use XXXXXXWebSocketDestination to create websocket connection and handle the incoming websocket request. The test cases are also added to guarantee it works.
>>
>> Please let me know your thoughts.
>> Thanks
>>
>> －－－－－－－－－－－－－
>> Freeman(Yue) Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>
>>
>>
>>> On Feb 28, 2017, at 10:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>> Hey Freeman
>>>
>>> You can with a JAXRSClientServerWebSocketTest (copy it to the undertow systests), add a CXF websocket transport dep and see if it can already work. Next try JAXRSClientServerWebSocketSpringWebAppTest in the undertow tests...
>>>
>>> Cheers, Sergey
>>> On 28/02/17 13:44, Sergey Beryozkin wrote:
>>>> 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 <sb...@gmail.com>
>>>>>>> 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:
>>>>>>> http://cxf.apache.org/docs/websocket.html
>>>>>>>
>>>>>>> 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
>>> http://coders.talend.com/
>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Freeman
Thanks, looks like it is all very much consistent with the way either
Servlet (JSR356) or Container-specific (Jetty and now Undertow)
WebSocket support is activated, nice work
Thanks, Sergey
On 20/04/17 07:18, Freeman Fang wrote:
> Hi Sergey,
>
> I just pushed my commit to websocket-undertow branch.
>
> The main purpose is for the standalone CXF endpoint(not CXF endpoint deployed into servlet container, as the AtmosphereWebSocketServletDestination should work with all servlet container implementing JSR365 now), using AtmosphereWebSocketUndertowDestination or UndertowWebSocketDestination when jetty isn\u2019t available on the class path. The original AtmosphereWebSocketJettyDestination still use jetty to handle the transport level stuff like read request and send response. Now in the WebSocketDestinationFactory I check if the jetty is available, keep things work as is, but if there\u2019s no jetty on the class path but instead undertow available, use the undertow counterpart ones. The logic here is quiet similar as before, when Atmosphere is available, use AtmosphereWebSocketXXXXDestination, if there\u2019s no Atmosphere, just use XXXXXXWebSocketDestination to create websocket connection and handle the incoming websocket request. The test cases are also added to guarantee it works.
>
> Please let me know your thoughts.
> Thanks
>
> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
>> On Feb 28, 2017, at 10:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>> Hey Freeman
>>
>> You can with a JAXRSClientServerWebSocketTest (copy it to the undertow systests), add a CXF websocket transport dep and see if it can already work. Next try JAXRSClientServerWebSocketSpringWebAppTest in the undertow tests...
>>
>> Cheers, Sergey
>> On 28/02/17 13:44, Sergey Beryozkin wrote:
>>> 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\u2019m 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
>>>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>>>> Freeman(Yue) Fang
>>>>>
>>>>> Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 28, 2017, at 6:38 PM, Sergey Beryozkin <sb...@gmail.com>
>>>>>> 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:
>>>>>> http://cxf.apache.org/docs/websocket.html
>>>>>>
>>>>>> 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!
>>>>>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>>>>>> Freeman(Yue) Fang
>>>>>>>
>>>>>>> Red Hat, Inc.
>>>>>>> FuseSource is now part of Red Hat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Freeman Fang <fr...@gmail.com>.
Hi Sergey,
I just pushed my commit to websocket-undertow branch.
The main purpose is for the standalone CXF endpoint(not CXF endpoint deployed into servlet container, as the AtmosphereWebSocketServletDestination should work with all servlet container implementing JSR365 now), using AtmosphereWebSocketUndertowDestination or UndertowWebSocketDestination when jetty isn’t available on the class path. The original AtmosphereWebSocketJettyDestination still use jetty to handle the transport level stuff like read request and send response. Now in the WebSocketDestinationFactory I check if the jetty is available, keep things work as is, but if there’s no jetty on the class path but instead undertow available, use the undertow counterpart ones. The logic here is quiet similar as before, when Atmosphere is available, use AtmosphereWebSocketXXXXDestination, if there’s no Atmosphere, just use XXXXXXWebSocketDestination to create websocket connection and handle the incoming websocket request. The test cases are also added to guarantee it works.
Please let me know your thoughts.
Thanks
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Feb 28, 2017, at 10:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hey Freeman
>
> You can with a JAXRSClientServerWebSocketTest (copy it to the undertow systests), add a CXF websocket transport dep and see if it can already work. Next try JAXRSClientServerWebSocketSpringWebAppTest in the undertow tests...
>
> Cheers, Sergey
> On 28/02/17 13:44, Sergey Beryozkin wrote:
>> 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 <sb...@gmail.com>
>>>>> 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:
>>>>> http://cxf.apache.org/docs/websocket.html
>>>>>
>>>>> 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
> http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Freeman Fang <fr...@gmail.com>.
Hi Sergey,
Thanks for your detailed answer, I will experiment all your suggestions.
Best Regards
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Feb 28, 2017, at 10:07 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hey Freeman
>
> You can with a JAXRSClientServerWebSocketTest (copy it to the undertow systests), add a CXF websocket transport dep and see if it can already work. Next try JAXRSClientServerWebSocketSpringWebAppTest in the undertow tests...
>
> Cheers, Sergey
> On 28/02/17 13:44, Sergey Beryozkin wrote:
>> 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 <sb...@gmail.com>
>>>>> 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:
>>>>> http://cxf.apache.org/docs/websocket.html
>>>>>
>>>>> 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
> http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hey Freeman
You can with a JAXRSClientServerWebSocketTest (copy it to the undertow
systests), add a CXF websocket transport dep and see if it can already
work. Next try JAXRSClientServerWebSocketSpringWebAppTest in the
undertow tests...
Cheers, Sergey
On 28/02/17 13:44, Sergey Beryozkin wrote:
> 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\u2019m 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
>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>> Freeman(Yue) Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>>
>>>
>>>
>>>> On Feb 28, 2017, at 6:38 PM, Sergey Beryozkin <sb...@gmail.com>
>>>> 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:
>>>> http://cxf.apache.org/docs/websocket.html
>>>>
>>>> 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!
>>>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>>>> Freeman(Yue) Fang
>>>>>
>>>>> Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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\u2019m 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
>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>> Freeman(Yue) Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>
>>
>>
>>> On Feb 28, 2017, at 6:38 PM, Sergey Beryozkin <sb...@gmail.com>
>>> 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:
>>> http://cxf.apache.org/docs/websocket.html
>>>
>>> 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!
>>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>>> Freeman(Yue) Fang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [DISCUSS]websocket transport with undertow?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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\u2019m 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
> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
>> On Feb 28, 2017, at 6:38 PM, Sergey Beryozkin <sb...@gmail.com> 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:
>> http://cxf.apache.org/docs/websocket.html
>>
>> 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!
>>> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
>>> Freeman(Yue) Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>>
>>>
>>>
>>>
>>
>
>
Re: [DISCUSS]websocket transport with undertow?
Posted by Freeman Fang <fr...@gmail.com>.
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. 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.
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 <sb...@gmail.com> 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:
> http://cxf.apache.org/docs/websocket.html
>
> 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
>>
>>
>>
>>
>
Re: [DISCUSS]websocket transport with undertow?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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:
http://cxf.apache.org/docs/websocket.html
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!
> \uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d\uff0d
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
>