cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
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]http://xnio.jboss.org/ <http://xnio.jboss.org/>
[2]http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#undertow-faq <http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#undertow-faq>

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 <sberyozkin@gmail.com> 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="http://cxf.apache.org/transports/http-jetty/configuration”
>> with
>> xmlns:httpu="http://cxf.apache.org/transports/http-undertow/configuration"
>> 
>> 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
>> 
>> 
>> 
>> 
> 


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