simplejee 入門級j2ee開源項目

按照對學員最不利的解釋就是，我免費教你學一段時間，你免費幫我工作一段時間。
這種模式
1、有些學員學的不太好，我們是虧的
2、有些學員學的比較好，我們是賺的
3、學的不好的，我們還是照常返還學費
4、學的好的，我們不多加薪酬

比較適合學生，與其花1w多到其他機構，不如在我們這碰碰運氣。

如果你設置了保持密碼，但又要切換用戶名，可以參看
http://support.embarcadero.com/cn/article/36969

工作過的兄弟們提點建議哇

太復雜了，沒必要這么復雜。
建議看看springside或則我們的simplejee。

JForum的代碼還比較清晰，但談不上強大，雖然一般也足夠用了。

再來支持一下

不錯，辛苦了，我們也用jbpm4做項目，但沒時間整理資料。

@珂兒

第一，這個服務不是面向商業公司的，雖然商業公司完全可以使用。比如我們公司，整的這個開源項目，用來做宣傳是重要目的之一。
第二，不僅僅是一個版本服務器，還有項目管理的一些功能。
第三，如果你在找工作，在上面發布個你認為能代表你的項目，我想還是不錯的。

推薦一下我們的simplejee項目，起初公司內部做培訓的時候，先是使用的appfuse做例子，不方便，后來使用springside，但對初學者還是頭疼，就產生了寫一個簡單的入門項目的想法，從那時開始到后來做對外培訓，慢慢的形成了這么一個簡單的，大雜燴型的項目。http://code.google.com/p/simplejee/

或者通過第三方軟件打成exe


呵呵，也可以借助eclipse的那個exe一下。
這個文章介紹的內容也不錯，推薦之
http://hi.baidu.com/zhme0268/blog/item/8da1dec6dd555fd5d1006086.html

和Apache有點類似
　　X-Forwarded-For
　　WL-Proxy-Client-IP

概念上好像不對，你的代碼只是截取域名后的第一段路徑，這個和context path是兩碼事，雖然在很多項目中是相同的，Contextpath還可能為空，這時你截取第一段路徑就是不對的了。
真要是需要的話，你定義一段javascript如下，應該更合適。
<script>
var contextPath = "<%=request.getContextPath()%>";
</script>

http://www.javaeye.com/wiki/simplejee
我們在javaeye上建的j2ee入門學習的專欄，剛開始做。

我還是習慣用annotation寫在action類里。

我們也在相關的工作，只是現在手頭項目太忙，這段時間沒再繼續。
你們做的還是滿棒的。

我們06年用qooxdoo做了一個財務教學軟件，感覺還不錯，但還是對程序員的js要求比較高。所以后來我們的策略，ajax只能為輔。

不過看到上面這些比較的圖表，看到的dojo都排到最后面，有點幸災樂禍，呵呵，我一直不看好它。

但現在感覺小軍刀的話，選擇prototy.js,jquery,mootools，而解決方案選ext。

我都不知道，網上那些技術文章，都干嘛吃的，就沒有一個gwt-ext的用戶遇到，靠。

***不好這么說的，具體做到這個的人還是比較少的，尤其是按比例來說。***

搞到2點多，我都服了。 我自己生寫html都搞出來了，gwt楞搞不出來，我草

原來發現，<meta http-equiv="content-type" content="text/html; charset=utf-8"/> 這個沒加。也是在一位仁兄的blog中找到，很難找啊。

這只是一種方法，或則你引入google map的js時指定其編碼為utf-8也可以。
去年某個時候google map的js編碼做了轉換，當時我因為一直在用，google切換的第二天我就發現了。不過我只在群里說了一下。

似乎ext對于找工作更有幫助些。

金蝶是滿特別的，雖然我對此類東東信心不大，所以根本沒去了解。

現在嗎，是自己在做，也不是為了所謂什么重復造輪子，主要是方便應對各種情況。

我們以前一個項目用的是東軟的，至少那個項目做的不太好，感覺設計上還可以，但問題比較多，好像是一個沒有做完的東東。

好久之前是自己寫，但不久就換用別人的了。
最開始用的是htmlarea，感覺不錯，代碼很清晰易懂。但后來不再維護了，好像他們整了個收費的版本。
現在省事就用fckeditor了。

@bluesky

tomcat5 還是 5.5之后就存在這個問題。

另外如果使用spring的話，可以使用其CharacterEncodingFilter，并建議將forceEncoding設為false，這樣可以接受客戶端不同的編碼。特別是使用ajax的時候。

雖然對我這不是新知識，但小伙子這么有共享精神，很是可贊。

@HiMagic!
是啊，而且還又match了一下，又成了獲取域名了。
不過我以前只知道在后臺獲取頭信息，這個到沒留意過。

@abao

我想appfuse的出名可能是因為他只做很基礎的內容，然后你可以自己擴展，也整出一個可以稱為框架的自己的東西。而國內的一些快速開發平臺可能太復雜，不適合學習了解內部機理。

我們現在是struts2,hibernate,spring是基于appfuse整合的。用起來很好，以前我們使用struts1.x，但通過結合spring的插件，效果上還是很類似現在的struts2，不過現在感覺還是struts2好，很不錯，大大的減少代碼，減少邏輯復雜度。

很有受益！
另外感謝關于我們的培訓計劃的留言，很有價值。

@lizhiyang

我只是根據項目中多了spring，hibernate后，容易造成這個問題，以及spring，hibernate會產生很多類這個角度來猜測是其原因，倒確實沒有正式確認過。

@saysoc
我倒沒再測試5，我現在都是在6下測的。

@stone2083
恩，我之前還不知道可以使用jstat進行觀察，剛才找了下資料。多謝。

經常見到這樣提供和索要軟件或文檔的，總是擔心樓主會少睡幾個小時。

連說帶評寫的不清晰，總結一下
1、修改tomcat的啟動參數，類似如下的樣子
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
2、將通用的lib文件放到tomcat的目錄下

建議大家還是深入了解一下Acegi，Acegi設計的思路和樓主有所不同。在Acegi里有用戶，授權，資源，以及在資源被訪問前進行權限的檢查。一個用戶可以有多個授權，一個授權可以對應多種資源，而資源可以多種多樣。在Acegi的默認實現了有url，方法，領域對象。而用戶和授權的關系，并不只是直接把授權交給用戶，還可以把授權分配給角色，給用戶組，給部門等，然后用戶和角色，用戶組，部門關聯起來，幾種分配方式可以配合使用。
按照這種思路，采用不同的授權方式，應該是可以用一套類似的程序，實現多種的授權方式。Acegi關注的夠底層，所以可以有更大的擴展，適應更多的情況。

建議大家還是深入了解一下Acegi，Acegi設計的思路和樓主有所不同。在Acegi里有用戶，授權，資源，以及在資源被訪問前進行權限的檢查。一個用戶可以有多個授權，一個授權可以對應多種資源，而資源可以多種多樣。在Acegi的默認實現了有url，方法，領域對象。而用戶和授權的關系，并不只是直接把授權交給用戶，還可以把授權分配給角色，給用戶組，給部門等，然后用戶和角色，用戶組，部門關聯起來，幾種分配方式可以配合使用。
按照這種思路，采用不同的授權方式，應該是可以用一套類似的程序，實現樓主所說的三種方式。

@BeanSoft

多謝，常交流。

我感覺開源有兩種，一種是興趣使然，一種是商業策略。
不管是哪一種多數開源項目都要花費大量的人力，自己的，或者公司的。
如果你不需要依靠你做的這個開源的東西謀生活，養兒女，開源并且免費，如果愿意的話。
我覺著這無可厚非，見到別人收費就罵，國外的可被咒罵的開源項目太多了，很多著名的項目。有些罵人的人就是便宜占不到了，心里難受。
另外如果你開源，先是給自己戴個大帽子，擴大知名度，然后再按照預謀好的計劃進行收費，這也不厚道。
開源和免費是兩碼事，有些免費的東西不開源，有些開源的東西不免費，國外還有些項目開源但是不提供文檔，或文檔很差，靠文檔和培訓收費。
簡單的說一個不要想著占別人的便宜，更不要占不到就罵人，另外一個不要即想做XX又想立牌坊。

對于web-rpc我用的就是json-rpc(現在叫jabsorb)，當然我們又做了修改，以便和spring結合，另外去掉了初始化的過程。
DWR的協議，還有國內的一些哥們寫的RPC的協議不太喜歡，DWR的人說他們會支持多種協議，并且說他們的功能比json-rpc強，反正我們用不著。

不錯，很清晰。

好，我會把本文介紹給我的開發伙伴。

@隨緣
hehe，我這邊的網絡情況下dependencies還滿好的，特別用了迅雷。

非常感謝

@一農fan
1、其實我修改的主要是其中的JSONRPCBridge類，把根據className獲取對象的方法和spring結合起來而不是像原來那樣從session中獲取。我貼出代碼沒有任何意義，因為這個修改很細微，只要你了解了json-rpc-java的JSONRPCBridge邏輯，自然而然就明白了。我就不想獻丑了，如果今后我把代碼優化一下，自己能滿意一點，或許我會貼出來，提高一下自己的抗擊打能力。
2、你讀一下dojo的代碼就明白了，比我做的方式對你更有益處。

高手開源的東西太多了，你有空余時間的話，可以花時間看看，我這個業余選手的東西實在是污染視聽，我做這個blog的目的是為了看看是否有公司需要類似的技術，招我做做兼職 :-)。
最近在找工作，被筆試，面試，烤的焦頭爛額，我本科不是學計算機的，現在是讀電子研，所以數據結構等抱抱佛腳學的一點東西，去考試真的滿痛苦。如果你是在校生，或想到一些大公司，不要花太多的時間去學這類技術，把數據結構，離散數學多學學，多練練。

這個只是js庫，可以在.net下使用。
只是其中的rpc現在他只提供了java和php的，不過當然你可以使用.net下的rpc。

@stoneboy
1、我認為這么理解是對的
2、3、你具體使用qooxdoo做些東西就曉的了，我還是推薦了解dwr，因為我用的json-rpc-java是經過我很多改造的，所以這里沒辦法討論。dwr返回的數據也是適用的json的格式。所謂json其實很簡單，http://www.json.org/，有點類似于Map，就是屬性結合的表示方法。至于同步，異步，你需要了解一下xhr，本質上dwr，json-rpc-java都是基于xhr的，可以參考這個網站 http://www.xmlhttp.cn/。
4、我的gmail郵箱是ynstudio

:-)，希望能有點幫助

關于樹，qooxdoo的效率不高，不過dojo似乎更低 :-)，節點多的話，當然要動態裝載了 :-)

@originxu
1、我現在做的一個正式項目就是使用的qx，已經接近尾聲。ui使用的qx，沒有采用什么特殊的東西。我就采用最直接的新開窗口，雖然消耗資源較多，但可以忍受。另外dojo蠻好的，可以考慮一下。
2、使用xhr載入js，和后臺沒什么關系，就是為了實現根據需要載入js。 對，json就是調用后臺注冊給spring的bean的方法，不過json-rpc-java本身沒有直接的實現方法。所以對于rpc，我建議你了解dwr。
3、json-rpc是基于xhr實現的，是為了模擬rpc的功能。我現在這個項目多數的操作界面，使用了qx的界面，都是使用json-rpc來與后臺進行數據交換。但有些功能是直接使用的常用的struts的方法。
4、這個也沒什么特別的地方。還和以前類似。因為還是請求響應。還是上面說的，因為我用的json-rpc-java已經不是原來的json-rpc-java了。你說提出的json-rpc的問題，我的回答估計對你也沒多少用處。還是看dwr就可以了 :-)
5、對我現在做的系統里并沒有考慮國際化的問題。如果我要做這個工作的話，我還真沒想好方法呢。如果使用struts+jsp的方式來實現現在的系統，有些標準的方法，但我總覺著不方便開發。現在拍腦袋想一下，如果是js文件里需要國際化的話，我會將需要國際化的文字加上一些特殊的標志，然后傳遞到前臺時，像jsp一樣進行過濾。

我發現dojo的樣式是通過元素的class定義的,所以如果要修改樣式,直接在當前頁面里重新定義這些class就可以了.
而qx的是通過元素的style來定義的,需要修改theme的相關配置,感覺和dojo相比不甚方便.
不知這個理解是否正確.