@huntter
是啊，我们的文档都使用docbook写的
简单来说。
“用户手册User Guide”中的东西是经过验证的，保证没问题的功能，可以放心使用。
“开发指南Developer Guide”中的东西还处于孵化器中，是试验性的，不敢保证没有问题。
jBPM-4.4的数据库表结构没有变更，但是jbpm.execution.hbm.xml里的duedue变成了dueDate，所以如果修改过这个映射文件，还需要同步一下。
re: IoC 问题域 临远 2010-07-12 08:52
目前来说，倾向于让IoC容器只管模块内部的事情，Ioc容器所面对的：1.自动组装，2.统一aop切面。这种Internal Ioc也可以通过OSGi的上下文获取注册的服务。不过也面对着一个问题，就是自动注册的服务还需要一个灵活的释放机制。
至于一个interface多个implementation的情况，倒是好解决。jsr250里Resource注解里可以指定name，spring提供的Quarified可以指定name，guice里可以用Named标示。OSGi可以用filter。实际上这是一个前置设计的问题，提前把可能存在哪些可能的选项都列出来。
re: Holder模式 临远 2010-06-23 11:09
OSGi引入了非常大的难度和风险，带来的好处也很明显。仁者见仁，智者见智了。如果用ThreadLocal而不是static作为Holder的媒介，就可以避免OSGi这类多classloader环境带来的隐形问题。
re: Holder模式 临远 2010-06-23 10:31
^_^holder随好用，但是不利于动态插拔，在OSGi的环境中，static也存在着陷阱。
呵呵，过来参拜一下使用spring-dm做项目的同志。还不清楚对cglib改造有什么用途，我们是使用暴力反射让hibernate实现动态注册实体类。spring基本已经被抛弃了。struts最后也没整合到osgi里，基本来说，改造以后系统已经不能通用了。期待博主的见解，多谢。
re: 关于Java缺乏多继承机制的探讨 临远 2010-06-02 12:40
如果实现了多继承，多个父类之间的冲突如何处理？
多谢支持，打算在spring security-3.1.0发布的时候重新搞一下 spring security，到时候会有视频。
@深夜两点
你看一下org.osgi.framework.Bundle的api javadoc。里边有你需要的方法。
其实没有这么麻烦，大家可以在bundle里看到有loadClass和getResource的方法，直接调用，就可以通过类名和资源名获得对应的资源。实际上内部也是利用了classLoader。
就像暴力反射一样，虽然一般不会这样用，但是也确实提供了让你为所欲为的可能。
@p27135
这些视频我们都已经测试过，可以正常下载，如果出现了问题，请尝试重新下载。
@lkj107
“技术人员多如牛毛”
真是一句中的啊，因为开发人员太多了，人们就说“只要拉来业务，出去随便找个人就可以实现，所以你不要诸多要求，要不明天就找个人把你顶了。”
事实确实如此吗？
@MyYate
最近感觉业务压死技术这种论调越来越嚣张，必须反击一下了。
@今夜很冷
公司的兴衰存亡，除了技术，业务，还有许多其他制约的因素，市场方向的选择，资金流，公司内部的结构关系，小公司死掉多数因为资金链断掉和本身市场定位的错误。你说要去阿拉伯卖雨伞，可以啊，自己选择错误就要风险，失败的原因也不在于我们研究技术是错误的，而是卖雨伞这个人太没眼光，就像鸦片战争前来中国卖礼帽的那个英国商人一样异想天开。
这是技术的错误吗？因为市场决策的问题，也要怪到技术部门的头上吗？应该是技术部门把业务部分吊起来打才对。回头想想，做技术的小公司哪个不是先找到技术过硬的同伙才敢接项目的，一个做技术的人都没有你业务再牛有用么？
你项目能力强，接来的项目自己做不完，拿出去转包，建议再拿出这副嘴脸，指着接项目那些人的鼻子告诉他们：“业务比技术重要，你们做技术的都没用，赶快把这些东西做了，我随便给你们两三块钱把你们打发了就行了。”到时候看对方咬不咬你。嘿嘿。：）
@atend
嘻嘻，还是那个问题，既然业务比技术重要，为什么要花几个月，或者几年时间学习技术，而只需要几周，甚至几天时间就可以理解需求呢？
继续打听一下，既然认为：“业务比技术重要”而不是“两者同等重要”，这样提高“业务的地位”是为了达到何种目的呢？
@stone2083
个人感觉，即便分清了业务边界和技术边界，两者也本应当是同等重要的，互相扶持不可或缺的两者，到底是从什么时候变成“业务一方完全压倒技术一方”呢？
即便做好业务规划，在缺乏技术的情况下依然是束手无策，反而很少见到技术基础扎实，却无法实现顺利规划业务的。无论从学习曲线和理解难易角度来看，技术都占据了很大的比重。
而认为：“技术要服务业务”这种说法很容易被其他人理解成：“做技术的人要听从搞业务的人员的调遣”，可实际上两者只有分工不同，并没有完全的主从关系。所以，为何不能说为：“技术和业务需要互相扶持。”而一定要讲做：“业务肯定比技术重要啦”。用意何为呢？
事实就是技术比业务更难掌握，所以是否应该揣测一下，宣扬“业务比技术重要”的人希望得出什么样的结论呢？是“我们不应该去学技术吗？”还是其他什么？
@Jeff
“技术是工具而已”里面隐含着对技术本身的蔑视，可恰恰“仅仅是工具而已”的技术基础支撑着整体上层的业务结构，这就是为什么开发人员要通过成年累月的学习才能掌握技术知识，而进入公司以后没多长时间就可以熟悉业务进行实际开发了。不搞清表与里的关系，就会出现本末倒置的情况。
re: 我们为什么选择工作流 临远 2009-11-18 21:54
具体情况需要具体分析，对于简单的流程确实不需要使用复杂的工作流系统，不能因为流程简单就否认业务流程的存在，如何解决具体流程问题，选用何种解决方法则是另外一个问题了。
@george
这个PPT中的讨论内容是基于我们网站上Spring Security安全权限管理手册中ACL篇，现在这部分还只有三章，内容尚浅，希望起到一个抛砖引玉的作用，期待大家提出如何在实际中更好的应用ACL的更多建议。
http://www.family168.com/oa/springsecurity/html/pt04-acl.html
-_-这个月流量又超了，幸好已经是月底了，9月1号就又可以访问了。
@good
session fix和session伪造应该是一个东西，之后的章节里会详细介绍。
@metadmin
spring security第一目标是实现常用的web安全机制，倒也没看出把这些事情弄的多复杂，细粒度权限控制这边似乎做的没那么好，等讲到acl的时候再详细讨论一下吧。
re: “开源人”收费得罪了谁 临远 2008-03-11 10:42
咖啡同志提醒的很好，一定要小心别人眼红，背后捅刀子，国内网络还是比较乱的，小心为上，安全第一。