CXF HTTP Jetty5 To Jetty6

CXF的HTTP transport原本是基于Jetty5的，但是Jetty6提供了很多新的功能，例如NIO以及通过Comet和Continuations支持异步的Servlet操作。前段时间我的一项工作就是要让CXF 的HTTP module支持Jetty6。

现在这一工作告一段落，写下这篇文章和大家分享一下我的体会。

有关Jetty5到Jetty6的迁移可以参考这篇文章 

由HTTP module是一个CXF的一个基础模块，据说SVN的Branch功能支持有限（ClearCase功能的确强大。谁叫SVN是免费呢，咱还是忍了。），为了不影响 main line 的代码，我采取了以下方式来进行开发。

1。 拷贝 HTTP module 到 HTTP2 module

2。 在 HTTP2 module上面做修改 

3。 等修改差不多完成了，咱再把HTTP module 替换成 HTTP2 module

也许你会问这么做，创建了HTTP2之后HTTP上面的修改如何反映到HTTP2上呢？

开始我想这活大概一个月就完事了，由于HTTP比较稳定这一段时间的修改我可以手工完成。但是在具体操作过程中还是出了一些问题。

先是 HTTP2小改完，我出了一趟半个礼拜的差，等回来跑测试突然发现JettySSLSelectChannelConnector还是一个PreAlpha的状态，我后面又有其他的活，于是HTTP2就此搁置起来了。

这一搁置就是快两个月，期间HTTP module经历过十几次的改动。在这些改动中，有些同志顺道也改了一下HTTP2，但是有大概六七次的改动没有同步到HTTP2中。（别看我记的这么清楚，这些改动我都是一个一个从commit mail中找出来的，这也算是一个教训啊。）

更大的问题是，我没有意识到这么多HTTP的改动没有同步到HTTP2中，以至于前两天做3步操作的时直接将HTTP2的文件拷贝到HTTP中，而不得周末花了快20个小时手工完成了HTTP与HTTP2的合并工作。

XP ，提倡的拥抱变化，其精神就是要将修改变小，而且每次修改都是可以通过测试验证的，这样才能保证我的修改成本不高，可以在不做详细设计的情况下编码，并能够持续的进行集成。

我做这次合并的最大体会是，我没有仔细阅读commit mail来发现HTTP2已经和HTTP有很大不同的，同时由于测试覆盖面的问题，没有发现HTTP2丢失了那些改动，造成了我的3步迁移变成了代价很高的举动。

为了避免悲剧的再次重演，我得好好研究一下SVN Branch的功能，还有就是多写测试，写好测试。