CAS現在是一個越來越龐大的東西，和Spring捆綁的很深。什麼spring mvc webflow能弄的都弄上了。讓本來以爲可以很容易集成的事情，變成一種很糾結的工作了。
小工程用上真的有點大材小用，大項目（平臺式）又和現有的技術有點不一致，需要容忍一下垃圾（不用的東西，謂之垃圾，並無貶義）。
反觀其代碼，除了核心級接口，關於持久等的實現那是捆綁在spring 和hibernate很深了。而其對commons的引用就是處處開花，然而其用到的各個包也不過其中某幾個類，某幾個方法。
其也在想slf4j遷移，但代碼中仍然有對commons-log的引用，看來其的審查工作也做的不是很到位。對於stringutil等工具類的引用，那也是spring ，commons皆有，並未十分的統一。
看來這也與一波換一波的參與人相關了吧。這是每個做大了的企業都有的問題，人是一波波的換，但產品還需要升級，參與者的喜好和技能各不相同造成代碼思想各異，然後引入的庫也越來越多，不可避免進入臃腫的行列。
核心人物動態缺失和精力的分散，產品的升級週期就越來越長。從3.1到現在都好幾年了，可以做一點應證。
我想這個也是國內中小軟件企業之痛之困吧。
困着，有木無才。