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
