CAS现在是一个越来越庞大的东西，和Spring捆绑的很深。什么spring mvc webflow能弄的都弄上了。让本来以为可以很容易集成的事情，变成一种很纠结的工作了。

  小工程用上真的有点大材小用，大项目（平台式）又和现有的技术有点不一致，需要容忍一下垃圾（不用的东西，谓之垃圾，并无贬义）。

   反观其代码，除了核心级接口，关于持久等的实现那是捆绑在spring 和hibernate很深了。而其对commons的引用就是处处开花，然而其用到的各个包也不过其中某几个类，某几个方法。

   其也在想slf4j迁移，但代码中仍然有对commons-log的引用，看来其的审查工作也做的不是很到位。对于stringutil等工具类的引用，那也是spring ，commons皆有，并未十分的统一。

    看来这也与一波换一波的参与人相关了吧。这是每个做大了的企业都有的问题，人是一波波的换，但产品还需要升级，参与者的喜好和技能各不相同造成代码思想各异，然后引入的库也越来越多，不可避免进入臃肿的行列。

    核心人物动态缺失和精力的分散，产品的升级周期就越来越长。从3.1到现在都好几年了，可以做一点应证。

    我想这个也是国内中小软件企业之痛之困吧。

    困着，有木无才。