cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject [HEADUP] the http-undertow transport
Date Fri, 26 Feb 2016 04:03:30 GMT
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

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 

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.

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.

Freeman(Yue) Fang

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

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