cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: [HEADUP] the http-undertow transport
Date Mon, 29 Feb 2016 04:50:02 GMT
Hi Sergey,

The difference comes from underlying Undertow and Netty, they are different.

AFAICS, the main goal for Netty is an aync nonblock network IO framework, though Netty provide
a lot more than that. On the other hand, the main goal for Undertow is a flexible, lightweight,
embedded web server, so Undertow and Netty are on different layer. The IO framework used by
Undertow is XNIO[1], IMO the XNIO is the counterpart of Netty used by Undertow. Here is the
faqs[1] why undertow use XNIO but not Netty as IO framework.

[1] <>
[2] <>

Best Regards
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat

> On Feb 26, 2016, at 5:43 PM, Sergey Beryozkin <> wrote:
> Hi Freeman
> Just curious, what is the difference between Netty and Undertow CXF transports ?
> Thanks, Sergey
> On 26/02/16 04:03, Freeman Fang wrote:
>> Hi Team,
>> I just push commit to master to add cxf http-undertow transport.
>> This is pretty much like how the cxf http-jetty transport works but start an embedded
undertow server instead when launch a standalone cxf/camel-cxf endpoint.
>> As in Apache Camel there's already a camel-undertow component and in the upcoming
Karaf 4.1(which will use OPS4J PAX-WEB 6), there's also an undertow http-osgi service implementation,
so I think it should be good in CXF we also has a http-undertow transport so that end user
has more option to chose the http transport they wanna use.
>> Most configuration which works for jetty engine like threading/TLS/maxIdleTime/continuationsEnabled/handlers/host/port
are still works for undertow(of course here handler is the undertow style handler but not
the jetty handler), however the sendServerVersion/connector/reuseAddress not applicable anymore
in undertow(I will add a doc page soon).
>> For the end user who ever use http-jetty transport, if they wanna try the http-undertow
transport, they just need change the dependency from cxf-rt-transports-http-jetty to cxf-rt-transports-http-undertow,
and change the configuration xml(if there’s any) namespace to the undertow one.
>> e.g. replace
>> xmlns:httpj="”
>> with
>> xmlns:httpu=""
>> In the patch file I appended with CXF-6800 I just follow this way using a script
to replace the namespace in configuration files and those existing system tests running against
the http-jetty just passed with http-undertow.
>> NOTE, my commit to community master not change the existing system tests as I do
in the patch appended with CXF-6800(That’s just the tests on my own branch so that I’m
confident everything works with http-undertow as well). Also I ran camel-cxf related test
against http-undertow transport and they passed.
>> My commit have two new modules
>> rt/transports/http-undertow
>> This is similar as the rt/transports/http-jetty, but no Undertow specific Continuation
Provider/Wrapper because we reuse the general Servlet3ContinuationProvider which will call
into Undertow implementation of Servlet3 async api.
>> systests/transport-undertow
>> Where I revise several http-jetty system test to demonstrate how the https/Session/Continuation(Servlet3
async api implementation in undertow)/ThreadPool/Undertow Handlers(for BasicAuthTest and DigestAuthTest)
works and configures with http-undertow.
>> Any feedback is appreciated.
>> Thanks!
>> -------------
>> Freeman(Yue) Fang
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message