@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
咖啡同志提醒的很好，一定要小心別人眼紅，背后捅刀子，國內網絡還是比較亂的，小心為上，安全第一。