amp@java

    JSF只能采用POST的方法進行FORM提交，同一頁面要顯示不同的內容，只有通過POST來改變參數或者通過SESSION傳遞變量。有時候有大量相似的頁面，這些頁面只有很少一部分不同（例如不同用戶、不同角色、不同頁碼等），通過跟在URL后面的query string本來可以很容易地實現，但在JSF里卻不行，只要一提交，馬上就把?后面那串東西丟掉。假如有一個頁面，根據URL后面的id參數來顯示FORM的內容，提交的時候如果驗證出錯，那個FORM的內容就丟失了，顯示一個莫名其妙的頁面，因為這時候那個id參數已經沒有了。還有常用的分頁操作，本來在URL后面加上個頁碼就可以了，但是JSF的分頁控件卻只能通過POST來翻頁，一刷新就出來個“重試”“取消”的對話框，讓人煩惱。如果頁面內容根據不同用戶角色有細微不同，就得每個角色建立一個頁面，每個頁面對應一個managed bean，這些頁面的內容基本相同，bean的內容也基本相同，卻要分別建立，一點重用的機會都沒有。今天做的一個東西就遇到了這種問題：
一個簡單的審批流程，只有3個角色，申請者、審批者、執行者，整個流程是這樣的：申請者填單->審批者查看并審批->執行者執行并填入結果->申請者查看。這樣，每種角色都有兩種列表：未回復和已回復，這兩種列表在三個角色里面都是相似的，但有細微區別：

	申請者	審批者	執行者
未回復列表	自己已發出但未被執行者執行的列表	申請者已提交但自己未審批的列表	審批已通過但自己未執行的列表
已回復列表	自己已發出且執行者已執行的列表	申請者已提交且自己已審批的列表	審批已通過且自己已執行的列表

這些列表的不同之處在于：已登錄用戶的角色（可以從session中得到，但一個用戶可能有多種角色，他可能以不同的角色查看列表），列表的當前狀態（對每種角色都有兩種狀態），列表的頁碼。由于每個列表都有可能有大量數據，所以必須用到分頁。通過JSF的DataTable空間和DataScroller控件可以簡單地實現分頁，然而，這種分頁導致URL后面的參數無效了，這樣一來，這六種列表就必須通過6個頁面來顯示了，通過頁面的名稱來區分當前用戶的角色、所查看的列表的狀態，每個頁面通過POST來決定頁碼。本來一個頁面+一個bean+3個參數就可以決定，現在需要6個頁面+6個bean來完成了。

list.jsp?type=0&role=0&page=1->type0_role0.jsp
list.jsp?type=0&role=1&page=1->type0_role1.jsp
list.jsp?type=0&role=2&page=1->type0_role2.jsp
list.jsp?type=1&role=0&page=1->type1_role0.jsp
list.jsp?type=1&role=1&page=1->type1_role1.jsp
list.jsp?type=1&role=2&page=1->type1_role2.jsp

假如有n種狀態m種角色那豈不是要n*m個頁面+n*m個bean？

有點想放棄JSF這個雞肋了。

希望有高手給條生路走走！

剛剛才知道，原來Java的線程是不能重啟的，也就是說，當線程的run()方法執行到最后一行，退出之后，這個線程就結束了，不能再通過start()方法重啟啟動這個線程，只能重新構造一個線程對象，再調用其start()方法來啟動，但這個對象和原來那個對象已經不同了。
為了實現某個線程對象的“重啟”功能，可以在它的run()方法的最外層加上一個循環語句：

這樣，只要stop不為true，run()方法就不會結束，不斷地“重啟”。
如果run()方法里面還有一個循環，那么就要兩個停止標志：
這樣，如果需要“重啟”線程，只要把restart設為true即可，如果要退出線程，只要把stop設為true即可。

之前用過一個帶CheckBox的Tree控件，叫dhtmlXTree，支持xml數據，功能很好很強大，但是有個問題怎么也解決不了，不知道什么原因，就是第一次顯示的時候能夠正常顯示樹形列表，但第二次進入相同頁面就會顯示錯誤，所有圖片都看不見，只看到其中的文字，而且這時候整個瀏覽器像死了一樣，點擊上面的任何鏈接都沒反應，必須關閉重新打開才有效，或者等上十幾分鐘才反應過來，不知道是不是一直在后臺運行某個Javascript腳本。雖然這個控件的源代碼可以看到，但是一條注釋都沒有，都不知道哪個部分出了問題。

在google上搜索替代方案時，看到了BlueShoes的樹形控件，具有多種形態，包括CheckBox，RadioButton等，每種形態都有例子，而且有詳細的規范的文檔（phpdocument，與JavaDoc類似），關鍵是代碼里面也有詳細的注釋，可以看到每個部分的實現原理。與dhtmlXTree使用XML存儲數據不同的是，這個樹形控件使用多維數組來存儲數據，似乎可讀性和效率稍差，但出錯的幾率也少了，不需要用到瀏覽器的XML處理。與前者一樣也支持IE5。

關于BlueShoes的樹形控件的詳細的情況可以看這里：http://www.blueshoes.org/en/javascript/tree/

那個網站上還有很多其他控件，也是很優秀的，雖然它的后臺是php框架，但客戶端控件同樣可以用于JSP。

瀏覽器的緩存有時候顯得很討厭，明明已經更新了內容，就是不顯示新的，只要URL不變，瀏覽器就不會去檢查服務器是否已經更新，而是用緩存里的東西，起碼在IE里是這樣。
使用AJAX經常需要動態更新某一過程的狀態，例如短信發送的狀態，如果相隔幾秒查詢一次，URL不變的話，顯示出來的狀態永遠不會改變，因為瀏覽器第一次獲取了內容之后就不再更新了。
為了解決這個問題，最簡單的辦法就是在URL后面加上一個不斷改變的查詢字符串（query string），例如：
request.jsp?q=q&date=(new Date()).getTime()
紅色部分就是不斷改變的查詢字符串。

感謝http://wangcheng.javaeye.com/blog/135887的提示

http://batmanwl.blog.sohu.com/71841783.html這里還可以看到多種解決方案

通過JavaME的WMA可選包發送短信時，手機會提示是否允許程序發送該短信，雖然不太影響應用，但每次都要按一下允許也很不爽。從網上看到有人說對jar包簽名后就不會出現這種情況了，但是簽名的證書要向兩個大公司買，因為手機里面一般只內置了那兩個大公司的根證書，而且手機不允許安裝新的根證書，這不分明是圈錢嗎？不知道當初制定這個標準的家伙收了那兩個公司多少黑錢！雖然這樣會使很多病毒不能運行，但是那兩個公司又不是上帝，給錢就可以買到證書了，他們又沒什么力量也不會去研究購買證書的人要干什么，如果有惡意的人只要花點錢，同樣可以造出帶簽名的病毒來。
但是辦法總是有的，有人另辟蹊徑，通過非常手段給手機安裝一個自己制作的根證書。詳細過程可以看這里：http://browndrf.blogspot.com/，原理就是利用了NOKIA某些型號的手機可以通過web下載證書并安裝的漏洞。我實驗了一下，整個過程其實不用那么復雜，不需要用到NOKIA的簽名工具，直接用SUN WTK的簽名工具就可以了，也不需要通過網絡安裝程序，跟平時安裝沒簽名的程序一樣。
然而，簽了名的程序同樣需要確認才能發送短信！而且比沒簽名的程序更麻煩，還要在MIDLet-Permissions里面填上一大堆許可，不簽名的軟件這個項根本不用填。唯一的好處是安裝的時候不會提示程序不受信任，而且不能用無簽名的同名程序覆蓋。但是這種安裝過程的問題并不需要多大關注，因為安裝只是很少的時間，關鍵是使用。
后來在這里：http://blog.csdn.net/zhengyun_ustc/archive/2006/04/07/654226.aspx又發現一篇文章，說明能夠安裝根證書的不過是個別機型的漏洞，是不符合MIDP 2.0安全標準的，算了，這個問題還是沒法解決，死心！
JavaME真的有點像雞肋，它最大的優點是跨平臺，但各種手機的支持程度又各不相同，一點點小的差異就搞得人暈頭轉向。而且各種各樣的限制使得它最多就弄點小游戲玩玩，要連接網絡還得一堆的許可，程序大了還容易莫名其妙地崩潰。真是食之無味，棄之可惜。
可是，我還是要搞……

Bouncy Castle（http://www.bouncycastle.org/）是一個龐大的加密類庫，支持Java和C#，其中Java部分發布的源代碼壓縮包就有24M左右，支持JDK 1.0~5.0，支持J2ME（現在叫JavaME）。
但是，這個類庫使用起來并不那么方便，它并沒有與普通Java類庫那樣以Jar形式發布立即可用的二進制類庫，而只發布源代碼，源代碼包含了多份，包括JDK1.0,JDK1.1,JDK1.2,JDK1.3,JDK1.4,JDK1.5,J2ME等，每種環境都有少量文件不一樣，有多個用于Ant的build xml，分別用于各種不同的JDK，但是每個xml定義了多個target，不知道哪個target才能build出可用的類庫來，選中了其中某個target有可能會出現錯誤，build不下去。文檔太簡單，基本沒講到怎么生成可用的類庫，網上的相關文檔也很少。我嘗試了兩天才終于把第一個MIDP加密測試程序運行成功。
我的應用只是實現Java ME的加密，所以這里講的只是針對JavaME的，JavaSE應該會簡單一點。

打開下載下來的壓縮包（crypto-138.zip），會發現里面有一堆文件夾和一堆文件，其中一個文件夾叫j2me，于是第一反應就是打開它看看里面是什么，發現里面只有少量的源代碼文件，看來這只是適用于j2me的一部分源代碼而已，其他通用的部分不在這里。
還有一個j2me.xml，是一個Ant的build文件，在eclipse里面用ant打開以后，發現里面有很多target，除了what（輸出一些信息）和init（建立幾個目錄，復制一些文件）這兩個能執行成功之外，其他幾乎都是失敗的，所以通過這個東西是搞不出我們可用的classes來的。
沒辦法，只有一個個目錄地看，在一個zips目錄里面發現cldc_sources.zip，里面的源代碼文件有很多，有點像了，于是就把它解壓后放到一個Eclipse ME測試項目的src目錄下，找到org.bouncycastle.crypto.examples包，里面有個MIDPTest.java文件，還有個midp_test.jad，看來這個是用來測試用的MIDP了，調出WTK的模擬器來運行一下，果然是，成功了。
下一步是在手機上運行。如果不混淆，生成的JAR包有1.6M之巨，不管了，先試一下。安裝到手機上，到最后出現“授權失敗”的提示，安裝不成功。記起原來找文檔時在index.html里面看到有這么一句話：The final caveat to this is that as the j2me distribution includes some compatibility classes starting in the java package, you need to use an obfuscator to change the package names before attempting to import a midlet using the BC API. 似乎因為用于j2me的版本有幾個以java開頭的包，里面包含了一些兼容類，可能是用于補充CLDC的不足，由于java開頭的包是系統包，是不允許修改的，所以不處理過的話安裝會失敗。必須先用混淆器弄一下才行。Eclipse ME配置混淆器十分簡單，我使用的是ProGuard。參照http://www.cnjm.net/eclipseme/docs/configuring.html配置即可。然后運行Create Obfuscated Package生成混淆過的包，只有13K。安裝在Nokia 6681上，成功，運行，也成功了。嘗試修改一下MIDPTest.java，在whichCipher方法里面，把返回值改為其他數字（0-4），就可以修改加密方式，但是由于DES加密使用的密鑰長度為64bit，而默認的key是"0123456789abcdef0123456789abcdef"，運行DES是會提示密鑰太長，我開始以為把key改為4個字符就可以（因為Java使用Unicode，每個字符2字節，4個字符8字節=64bit），卻出現了數組越界的異常，其實這個key并不是直接用作密鑰，還要經過處理的。嘗試了8個字符也不行，最后發現16個字符就可以了，應該是每兩個字符對應一個16進制數。測試程序是對“www.bouncycastle.org”這個字符串進行加密和解密，速度還是挺快的，幾乎感覺不到需要時間（在手機上啟動Java程序本來就比較慢）。

中間還碰到一個問題，由于我是把源代碼直接復制到一個原來建立好的MIDP項目里，那個MIDP項目里已經有個默認的JAD文件，但是里面沒有表示要運行的Midlet，生成Jar包之后，安裝到手機上到最后會出現安裝文件無效的提示。打開那個JAD文件，在Midlets標簽里點擊Add按鈕，把org.bouncycastle.crypto.examples.MIDPTest添加進去即可。

以上測試使用的環境是：
JDK 1.5.02
Eclipse 3.2.0
Eclipse ME 1.7.7 http://eclipseme.org
Sun WTK 2.5.2 for CLDC
ProGuard 4.1 http://proguard.sourceforge.net/


剛剛發現Bouncy Castle的下載頁面http://www.bouncycastle.org/latest_releases.html里面有專用于J2ME的源代碼發行包，里面只包含用于J2ME的代碼，如果僅用在J2ME下的話，這個應該比較簡單，不用找半天。

有時候我們需要通過程序自動發送一些純文字的信息，通過SMS可以達到目的，但當文字達到一定長度時，就必須分割成多條短信（一般60漢字一條），增加了費用，通過MMS可以解決這一問題，MMS最大支持100KB的內容，假設每個漢字3byte（使用UTF-8編碼），能發送33K個漢字，一次可以發送一篇文章了。
Now SMS/MMS提供了一個Web界面用于發送彩信，通過Apache HttpClient，我們可以模擬瀏覽器的行為向web服務器提交表單，發送彩信。Now SMS/MMS的Web界面提供了很多選項，但發送純文字彩信的話我們只需要填寫接收者，主題（可選），內容即可，把對應的表單內容POST到當前頁面，就能發送一條彩信。（待續）

Now SMS/MMS是一個強大的短信/彩信發送服務器，它內置了彩信中心，在某些運營商的網絡內可以通過普通的短信貓發送彩信，而不需要使用支持GPRS的短信貓，也就是說系統本身就具有了運營商的彩信中心的功能。然而，在中國移動的網絡內是不能實現這種方式發送彩信的，必須通過移動夢網的彩信中心轉發。
彩信的發送其實是兩個過程：
1、向目標手機發送一條普通的提醒短信，其中包含了發送者號碼、彩信的URL等信息，該URL指向彩信中心的某個web目錄下的某個彩信文件；
2、目標手機接收到這條提醒短信后，主動發起GPRS連接，根據短信中的URL向彩信中心提取該彩信，并顯示出來。
Now SMS/MMS 自帶的彩信中心其實就是一個支持手機連接的web服務器，它把制作好的彩信放在某個web目錄下，手機連接時就可以下載。
然而，實踐證明，如果使用中國移動的SIM卡，無論使用的是什么短信貓，都不能通過系統自帶的彩信中心發送彩信。
要設置成通過移動公司的彩信中心發送彩信，必須把系統的默認設置——使用自帶的MMSC（彩信中心）——改為使用移動公司的MMSC。方法如下：
在Now SMS/MMS Gateway配置程序中選擇MMSC Routing，然后點擊Add按鈕，在彈出的對話框中建立一個新的MMSC配置，其中Acount Name和Account Description可以隨便填，只是用來識別配置名稱，因為系統可以設置多個MMSC。Default Sender Address必須留空，否則發送很難成功（有極少部分能夠發送成功）。Allow Sender Address Override前的復選框也必須留空。Route messages to this account for recipient phone number(s)不用填（這是一個掩碼，只有符合要求的號碼才用這個路由，按照官方文檔的說法，不填的話是不會用這個路由的，但實際上把它設成默認路由的話，即使不填也會用這個，也許填上+861*,1*會好些，表示中國的手機都用這個發）。Route messages to VASP via選擇MM1，之后會出現更多的輸入框，點擊Look up Operator Seetings，出現一個選擇運營商的對話框，很幸運，中國移動在里面，選擇China - China Mobile，然后OK即可，系統自動把適合中國移動的內容填了進去。但是Network Connection和Modem Used兩個下拉列表還沒選好。這里必須使用對應的GPRS貓的調制解調器（在控制面板-電話和調制解調器選項-調制解調器-添加，按照提示一步步就能找到GPRS貓，看好哪個調制解調器對應哪個端口，從而知道哪個調制解調器對應哪個GPRS貓）。填好這些東西后點擊Test Connection可以檢測連接，成功就可以了，檢測時間比較長，要耐心等待。填好之后點擊OK，在MMSC Routing標簽頁里的Additional Routes里面就能看到剛才的那個配置名稱，然后在Default Route里面選擇剛才的配置名稱作為默認路由就可以了。
之后打開MMSC標簽，配置自帶的MMSC。雖然我們使用的是中國移動的MMSC，但通過web發送彩信時，必須先發送到系統自帶的MMSC，再轉發到移動的MMSC，所以必須把系統的MMSC也配置好。這里就是普通web服務器的配置（還有SMTP的配置，可選），把端口和IP選好后，還要注意Local Host Name or IP Address里要填入一個本機的IP，如果在僅在內網使用，可以直接填本機IP（外網的情況沒有研究過，看看說明書先）。其他默認的就可以了。
再打開Web標簽頁，把Web服務器配置好。
打開瀏覽器，輸入http://服務器IP:web服務器端口/，就能看到發送各種短信、彩信的鏈接，然后就可以發送彩信進行測試了。如果發送不成功，可以打開Serial #標簽頁，把底下的三個Debug選項都勾上，再發送一下，然后在Now SMS/MMS 的安裝目錄下找到MMSCDEBUG.LOG等幾個LOG文件查看究竟是什么問題。文件太大會導致發送失敗，系統不會自動檢查的。文件大小的上限還不清楚，但超過100KB似乎就肯定不行。
今天搞了一天這個東西，終于能正常發送彩信了。在這里備忘一下。慢慢再作深入研究。

感謝：http://blog.csdn.net/phiger/archive/2006/12/19/1449176.aspx

官方文檔：http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_content/Connecting_to_operator_MMSC.htm#SendingMMSMessages

一個使用了JSTL的JSP頁面，當字符集設為GB18030時，總會隨機的出現一些亂碼，莫名其妙的，有時候有，有時候沒有，刷新一下可能會變，也可能不變；最令人懊惱的是，利用JSTL生成的JavaScript語句經常會漏掉一兩個字母，害得整個JS程序段出錯，每次漏的字目都不一樣，根本沒法改。
似乎google搜不到相關信息，沒辦法，后來把編碼改為UTF-8，就不會再出現這種情況了，但不知道以后還會不會出現。
有時候上網易，也會見到一些字符出現亂碼，刷新一下就沒有了，看來這是JSP的通病，為什么就沒有人提出解決方案呢？

通過JDBC-ODBC橋連接某個ACCESS數據庫，并把一個逗號分隔文本文件插入到某個表中，如果插入過程中沒有其他程序使用該數據庫，只需要20多秒就可以完成；如果插入的同時，還用ACCESS程序打開了那個mdb文件，雖然沒有任何操作，但運行相同的插入程序，竟然需要80多秒，性能下降4倍！！
ACCESS=垃圾！