开源之痛-从ACEGI到Spring Security

Acegi到了1.0之后就Game over了，之后则以Spring Security的面孔出现在Spring家族中。版本也到2.0，支持openid等等多种功能。为了想看看Spring Security支持不支持Mutli Target Home Page 这个需求，合不该动了念头决定将ACEGI迁移Spring Security。

先翻翻配置文件...My god，已经和ACEGI完全不同，等于得重新学习一个新的框架（尽管理念还是类似的），接踵而来的是满肚子问号：我的hibernateDaoProvider要从哪里塞进去，和Jcaptcha要如何整合？原来的Success Failed Event log要如何配置...这些在ACEGI颇为折腾的问题，如今又得重新折腾一次。

而其中以Jcaptcha的整合最为头疼。

开源的痛楚，在于有时候版本开发过于随性，未曾考虑过用户的迁移，也未提供工具来帮助用户迁移，每一个版本推出，常常伴随着阵痛。痛并快乐着。

PS:

我从来不觉得配置文件算什么知识点，ACEGI太复杂的配置简直是误区。

这算什么痛.
上次有个朋友的公司06年的时候用了当时MS鼓吹的智能客户端CAB框架,那个时候炒得风风火火,等人家两个项目做下来,到了07年上半年,居然MS把开发组解散,CAB项目站点迁移,最后直接停滞了事.这叫靠在CAB上面的那些公司乍活啊.要升级没升级,要资料老得要死,碰到个技术问题连同道都找不到几个.
开源项目还算好了,至少源代码公开,而且类BSD的license你自己改巴改巴也没风险.碰到问题你至少还可以翻代码.知足吧.

俺还不至于那么笨，要去改吧改吧一个框架，等改吧改吧出来，项目时间早就过去了。


PS:

你举的例子压根是错的，大有编造之事实。

SmartClient 这些Application Block大部分都是开源的，贡献给Codeplex站点了。应该象你一样改吧改吧才对。

CAB：
http://www.codeplex.com/cabextensions

哪个事实错了？ 难道说早先的那个开发组还在？还是CAB项目站点没迁移？一开始就宿主在codeplex?
说话要带点把门的吧。



最后贡献给了codeplex不假，也只能说是MS把自己的相关开发组解散以后的扔垃圾行为，真把开源当垃圾桶啊。你既然找到了这个页面，难道没发现这个CAB被贡献以后就没一个版本出现过？开源是不假,但是一个无人认领的项目(千万别扯那些所谓的项目组成员,那帮人自从把这个项目完整上传以后就没贡献过一行代码),把它和开源项目相提并论,只能说是在混淆视听了.
难道一个商业公司炒作概念,把人忽悠上船之后,因未知原因二话不说立马把开发维护力量解散,把源代码一公开,就能够免责? 就CAB而言,只能说是MS在所谓的开源地界给它找了个坟墓.
对于用户来说,使用这类商业公司的东西,难道相比于正经的开源项目有更强的保障?看来看去只有更大的风险.你连开源项目升个新版本改了API就开始痛了,商业公司这种把项目代码一公开就把项目组关门大吉的行为,还不让你痛得要死.至少,就开源项目而言,人家的开发团队还在,老版本照样有人在提交patch.不比MS的做法强得多得多.如果说acegi的做法是未曾考虑到用户的迁移,那微软的做法,就是未曾考虑过用户,纯粹的玩一把就把你玩死.

至于改吧改吧的问题,偶对MS的东西不感冒.而对MS感冒的那帮家伙,一看MS都把这个玩艺儿"捐献"到死了,谁还敢在这个方向上混.要知道,在.net这一亩三分地,MS就是天.他说这玩意是个死东西,它就肯定是个死东西.
且看CAB这个项目最近一个月的状态:
PageViews:531
Visits: 227
Work Items Closed:0
Discussion Posts:0
加上自捐献以来没一个新版本发布过(甚至之后就没更新过一个文件和上传过一个patch),不就是活生生的微软式捐献即入土的典范?

这个。。。acegi 确实是个问题。

我还没用过Spring Security 。改天用一下，看看如何。

个人感觉1.0的Acegi配置还好了。一般那几个IOC的都是固定的。只是在datasource那一块需要电变动。

希望 新版本的 能更好用啊

acegi-1.0.x迁移到spring security，有两种方法可选择。

 

1.是用原来acegi的那种超复杂配置方法，将包名类名做对应修改后，即可。
问题是，为了支持rest，web filter拦截器里有不少方法的api都改了，加上了method参数，像springside里那样提供的扩展子类都需要修改
jcaptcha，看spring security论坛上说，因为原先提供代码的作者失去了联系，项目组害怕这部分代码有问题，就先放在svn的sandbox下了，需要同志们自己copy到项目里。

2.是使用新的namespace配置方式。感觉用默认的方法还是比以前简便太多了。不过暂时还不知道怎么进行扩展。
那个什么provider应该可以通过自定义userDetailsService来实现。我们正在以非常缓慢的速度翻译spring security-2.x的文档，里边提到了一些扩展的方式。

 

(翻译)Spring Security-2.0.x参考文档”机制，供应者和入口“
(翻译)Spring Security-2.0.x参考文档”信道安全“
(翻译)Spring Security-2.0.x参考文档”支持的基础设施“
(翻译)Spring Security-2.0.x参考文档”技术概述“
(翻译)Spring Security-2.0.x参考文档的”使用命名空间简化配置“部分

 

 

PS:ray_linn老大对于java和开源社区的态度依旧啊。可兄弟们以后还打算靠spring security赚点儿小钱，所以不能看它被一竿子打死了。主贴中有几个小问题稍微说一下：

 

acegi到了1.0之后还在慢慢的推出bug fix，现在已经是acegi-1.0.7了，这个版本是和spring security-2.0一起发布的，所以，如果同志们不想一下子升级到spring security还可以使用以前的acegi。

 

配置文件完全不同的问题，不是一定要用新的配置方式，原来的xml配置方式依然可用（把springside-2.0改了一下，证明可以用），作者只是推荐大家使用新的简便的配置方式，把几百行的配置缩减成几行。再说他也提供了扩展点了（虽然暂时还不会用），这些在文档里也都有所提及（虽然据说他们文档中使用的英语很不地道）。

 

jcaptcha的确是个大问题，不过也提供在sandbox里了，出于安全的考虑没有直接发布成jar，可以通过svn直接获得，不过这个问题是在论坛上提出的，说明他的文档还有很大的改进的余地。

Acegi-1.0.7已经说了是final release了。

 

俺是烦丫为啥不提供个转换的wizard，三下两下就转换过去，读Acegi的doc已经够烦了还得读Spring Security。

 

俺的jcaptcha配置了几百行，加上acegi的几百行，越配越恼火。俺又继承了太多Acegi的类，改成Sping Security实在担心。

 

PS: Spring Acegi还是没支持multi Target Page，还是得自己继承ProccessingFilter，重写getDefaultTarget.

 

PS: javaeye这个新编辑器很难用。

“开源项目还算好了,至少源代码公开”--- 所有的Aplication Block最早都有提供源代码，俺自己都修改过UIPB的source，按你的说法，已经满足“至少源代码公开”的要求了。你也应该“知足吧”，何必对Microsoft怨言这么大？


引号内为你的原话。你的原话故意歪曲了Application Block带有source code的事实吧？

开源项目被扔垃圾的还少么？Spring Securtiy里的jcaptcha filter就是例子之一。

好吧，听了这么一说，有点不敢升级了。

智能客户端，MS的做法确实忒不厚道，想当初，哪可是火推了一把 ，还好没跟这股风