周五在通用产品部的年终总结会上，黎华说的一句话我特别赞同
“好的框架需要能够让用户有选择的使用，用户如果要是要这个框架，用户必须是有选择性地使用，如果有哪个功能不满足自己的需要，能够overwrite，不能好坏全收“
在说到框架的发展史，框架就像java的开发模式一样，是前人的优秀的经验的总结，使用了框架可以极大的提高工作效率。
但是，开发框架的人总是避免不了一个头痛的问题，他们开发的框架总是在解决一个特定领域的问题，场景稍有变化，先前开发的框架就会水土不服。
导致使用者不得不放弃使用当前的框架，而寻找下一颗银弹。
所以聪明的框架设计师终于发现，其实可以退一步，不关注具体业务场景的具体问题。把更底层的基础设施设计好，简单地说就是设计一个能够生成框架的框架。
比较成功的框架是 eclipse，hudson，还有 struts2，相信大家对他们都非常熟悉。 这三个框架解决的问题域各不相同，但是他们有一个共通点是基于插件的框架。
内部都有一个核心概念是 extension point，开发者可以基于extension point开发出自己的插件，很方便地放入到这个框架中实现自己想要的效果。
不知道是不是三个框架的设计者得到了马总的真传，说阿里巴巴不是只做电子商务的网站，而是要做电子商务的水电煤的基础服务。
大家都说struts2好，不能不承认struts2的确是一个非常优秀的框架，从webwork升级到struts2，让struts2能够发挥起生成框架的作用，打个比方吧，从零开始开发webx3框架需要3人年的工作量
但是，用struts2来开发和webx3所具有的一样功能的MVC框架的话只需要1人年就行了。
但是也正是因为struts2太灵活了，配置的弹性非常大，加上在开发过程中没有统一规范，在团队中每个开发工程师开发出来的代码，风格各不相同，从而大大增加了开发的复杂度。
对于一个团队来说需要的是统一，从这点来说，因为使用webx3这个框架，很大程度上统一了大家的代码。
再说到webx，通过这几天的使用，我觉得这个框架我觉得就整体实现的功能还是不错的，还是有不错的扩展性的，我想得到的问题，比如，防止重复提交，cookie安全问题都在webx框架中解决了。
这是它好的一面，也是它不好的一面，它试图解决的问题太多了，使得它显得臃肿了一些。启动速度很慢，真的很慢。
建议作者是否能够将更多功能做成可扩展的，比如，多component这个功能是不是可以按照调用者的具体情况，搞成可选的，因为这个是很费性能的。
基于threadlocal的 HttpservletRequest是不是也是可选的，因为如果在做comet，或者bigpipe的时候是要用到多线程异步write的，基于threadlocal的request就没有必要了。