超越次元的追求

設置<@pageEncoding=UTF-8>

關鍵在SwingUtilities.invokeLater(runnable);上,和線程沒關系

說得不是很清楚，但我直覺這樣的問題不是來自于依賴，而是設計方案導致的。
【組件C1和C2是兩個不同的業務組件，它們的UI中都有使用UIA這個組件】
從這個情形來看，后面的業務組件C1和C2其實應該是組合出來或是繼承出來，
而從經驗的角度看，可能以組合的方式更靈活一些。

BeanSoft的不錯,要是有一個native exe的就更好了,就一個小小監控還要開一個虛擬機有點大炮打蚊子的感覺

為什么一定要JDK1.5才能運行,做更大的范圍兼容對你很容易,也容易到幫助需要的人.

某些環境下(例如2K,JDK1.3,1.4)重定向對Java程序是不起作用的.

my god,居然還有人這樣用ww2,解藕解藕到了你這又成藕合了.

改為zip格式可以更方便網友使用.
公司機器沒法裝D版rar,打不開.

這是在寫技術文章,還是小學生作文?

我來解釋一下，很殘酷，但是請正視內心：
想實現夢想，但是期望走捷徑（家人幫等是你想免自己奮斗），工作的事情表示內心不想冒風險或者不想付出太大代價。
風險來了，跑不動被抓表示你想逃避，被抓后想法脫身表示你想避免道德的譴責（能挽回一點是一點）期望能趕上飛機，飛機代表的是成功。
你的這些潛意識都是很正常的，可以以更積極的態度去應對，每個人奮斗的過程，都是自我修煉的過程。

>核心資源掌握在別人的手里?
why？能說明白點么。

>我認為,權限(操作+資源)只有兩種,一種是需要資源的,另外一種是不需要要資源的.上面的四種,都可以歸并進去.
漏打了個"不"字
我的回復:
http://www.tkk7.com/wolfsquare/archive/2006/07/04/56606.html

我認為,權限(操作+資源)只有兩種,一種是需要資源的,另外一種是需要要資源的.上面的四種,都可以歸并進去.

>現實中你必須把角色、用戶、部門三者全部與權限掛鉤。
這么說是沒錯了,但是不作處理的直接掛鉤的話估計腦袋是被彗星砸過的亞.
>Action實現一個接口，接口里有一個 public boolean hasPermission() ，寫個攔截器攔截即可。
太麻煩了,每個Action都要寫,建議權限放在業務層來進行控制.
每種權限系統雖然概念類似,可是實現細節卻千差萬別,所以好用不好用,是馬是騾還得拿出來溜溜才知道.

AJAX框架出來了,才是Strust,Webwork們的競爭對手,不過,難道只有AJAX框架才能AJAX?WW們更容易達到這點吧,AJAX也許建立在既有的框架中,才是最好的出路.

第2點的abc三個理由都站不住腳.

研判:該項目經理應由你來擔任.

你這個Wiki的中文是怎么整出來的?

鉆個牛角尖,如果程序寫不出測試用例的情況呢?
例如復雜的GUI程序.

可以的，這是權限分離的最基本的要求，各個實體（公司，角色，人員）間對應的角色是分立的，無關的。從權限設置上來看：
組織結構一共有9種操作，其中前面三種不需要資源
adminRootUnit
adminRootPerson
adminRootRole
adminOrgUnit *
adminOrgPerson *
adminOrgRole *
deleteOrgUnit *
delteOrgPerson *
deleteOrgRole *
打了星號的操作是需要指定組織資源的，在這里，你可以將其等同于目標組織。

實際上，復雜的地方是需要子公司繼承母公司的權限的時候，要特別定制，當然，由于系統的目標是高度可配置，所以這點的代碼非常非常少。

加上了實體圖（最后一幅），RBAC以及其衍生類型已經非常成熟了，幾乎沒有什么可以討論的了。

呵呵，我們想法很有共通之處啊。
http://www.tkk7.com/wolfsquare/archive/2006/06/08/51227.html

建議大xia改名---芙蓉弟弟.

芙蓉弟弟....你又來娛樂大家了亞

不錯,贊一個.
這樣的文章比整天鼓噪自己的開源項目和團隊還在首頁吵架的文章要好多了.

沒了解過JDBMonitor，不過這么做就太“侵入”了。
我原來還以為是，照原驅動JDBC的寫法，在協議前加個標識listenerconfig=就好，其他照舊，為什么不這樣做呢？

google.com是在米國的
google.cn 才是國內的.

由于在本例中你舉例的場景不太合適,本來是解惑的東西卻讓人更迷惑甚至誤導,豈不是更糟?
期待你的改進版本.

既然你把自己的心得寫出來,那么必然覺得它有所用途.
既然它有所用途,那么自己就不會說出它沒有用的話,否則你說一個沒有用的東西出來有什么意義呢,基于想讓它有意義的理由,你的例子需要再舉得合適一些。

在這里似乎沒有多重繼承的必要.MessageClient已經能完成所有功能了.

>用例要盡快的翻譯為測試用例，而測試用例，正是為了更加準確的表述需求用例。
說的不錯,這次我支持你.

要是有PP就好了~

"原來極想擺脫的sql，但實現得又不如SQL成熟。"
這句是鉆牛角尖了。
hql 的提出是為了更好的可讀性。

還是Webwork爽,聲明即所得.
只需要在action里聲明public setFiles(File[] files){...}即可直接使用上傳到的文件,哪里用那么麻煩啊..

老莊的確深得傳媒本質的奧妙.

如果FinancialService 不幸的被聲明為了final.
如果又來了一個新子系統貨運子系統C或者更多目前還未知的子系統需要通知訂單通知..
還有很多如果如果...