|
這就是在前面的簡單應(yīng)用中,在view中,通過<bean:write name="myform" property="name">調(diào)用Actionform時出的問題,這個問題的直接原因很簡單就是:找不到"myform"這個Bean,用網(wǎng)上的話說就是“在Action里一般會request.setAttribute()一些對象,然后在轉(zhuǎn)向的jsp文件里(用tag或request.getAttribute()方法)得到這些對象并顯示出來。這個異常是說jsp要得到一個對象,但前面的Action里并沒有將對象設(shè)置到request(也可以是session、servletContext)里。可能是名字錯了,請檢查jsp里的tag的一般是name屬性,或getAttribute()方法的參數(shù)值;或者是Action邏輯有問題沒有執(zhí)行setAttribute()方法就先轉(zhuǎn)向了。
還有另外一個可能,純粹是jsp文件的問題,例如<logic:iterate>會指定一個id值,然后在循環(huán)里<bean:write>使用這個值作為name的值,如果這兩個值不同,也會出現(xiàn)此異常。(都是一個道理,request里沒有對應(yīng)的對象。)”。
??????我對Actionform的機制不理解,心中的疑問:
??????1)如果ActionForm是Struts自動封裝到Request中,那么我可以直接在view.jsp中,能過<bean:write>調(diào)用這個ActionForm,如果假設(shè)這種情況成立時,那么Beanwrite中的bean名應(yīng)該是ActionForm的類名,還是在Struts-config.xml里給ActionForm定義的類名?
????? 2)如果沒有封裝的話,那么是不是需要在Action中把Actionform通過request.setAttribute("","")放到request中
還是要放到Session中,
????? 我測試時候出的問題
?????? 有一次就是在1)的情況下測試成功的,但是以后再怎么試都不行,那次是引用的Struts-config.xml里給ActionForm定義的類名。非常奇怪,
????????還有就是2)的情況,測試中如果Action和Frombean在一個包下面,那么通過request.setAttribute("",""),就可以獲取到Bean,如果不是的話,有時候行,有時候不行,
??????? 如果通過request.getSession.setAttribute()設(shè)置ActionForm的話,每次都可以,他們的Scope肯定在一個Request中,那么為什么Session就可以,而Request不行。(結(jié)論:因為是在Actionfoward中設(shè)置了“redirect='true',這樣的話一跳轉(zhuǎn)時,Request中的內(nèi)容都會被重置,所以不行,把這一句去掉就可以了”)
源代碼
Strust-config.xml
1、插入和包含
???1)???js,一般都放在head之間、注釋的作用是當(dāng)客戶端瀏覽器版本過低時,不能識別而發(fā)生錯誤
<script?language="JavaScript">
<!--
document.write( "Hello?World!");
//-->
</script>
?2)另外你也可以編輯.js文件,然后在頁面里面直接引用就可以了
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>javascript</title><script language="javascript"src="Untitled-2.js"></script></head>
2、write
一、術(shù)語session
在我的經(jīng)驗里,session這個詞被濫用的程度大概僅次于transaction,更加有趣的是transaction與session在某些語境下的含義是相同的。 session,中文經(jīng)常翻譯為會話,其本來的含義是指有始有終的一系列動作/消息,比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個session。有時候我們可以看到這樣的話“在一個瀏覽器會話期間,...”,這里的會話一詞用的就是其本義,是指從一個瀏覽器窗口打開到關(guān)閉這個期間①。最混亂的是“用戶(客戶端)在一次會話期間”這樣一句話,它可能指用戶的一系列動作(一般情況下是同某個具體目的相關(guān)的一系列動作,比如從登錄到選購商品到結(jié)賬登出這樣一個網(wǎng)上購物的過程,有時候也被稱為一個transaction),然而有時候也可能僅僅是指一次連接,也有可能是指含義①,其中的差別只能靠上下文來推斷②。 然而當(dāng)session一詞與網(wǎng)絡(luò)協(xié)議相關(guān)聯(lián)時,它又往往隱含了“面向連接”和/或“保持狀態(tài)”這樣兩個含義,“面向連接”指的是在通信雙方在通信之前要先建立一個通信的渠道,比如打電話,直到對方接了電話通信才能開始,與此相對的是寫信,在你把信發(fā)出去的時候你并不能確認(rèn)對方的地址是否正確,通信渠道不一定能建立,但對發(fā)信人來說,通信已經(jīng)開始了。“保持狀態(tài)”則是指通信的一方能夠把一系列的消息關(guān)聯(lián)起來,使得消息之間可以互相依賴,比如一個服務(wù)員能夠認(rèn)出再次光臨的老顧客并且記得上次這個顧客還欠店里一塊錢。這一類的例子有“一個TCP session”或者“一個POP3 session”③。 而到了web服務(wù)器蓬勃發(fā)展的時代,session在web開發(fā)語境下的語義又有了新的擴(kuò)展,它的含義是指一類用來在客戶端與服務(wù)器之間保持狀態(tài)的解決方案④。有時候session也用來指這種解決方案的存儲結(jié)構(gòu),如“把xxx保存在session里”⑤。由于各種用于web開發(fā)的語言在一定程度上都提供了對這種解決方案的支持,所以在某種特定語言的語境下,session也被用來指代該語言的解決方案,比如經(jīng)常把Java里提供的javax.servlet.http.HttpSession簡稱為session⑥。 鑒于這種混亂已不可改變,本文中session一詞的運用也會根據(jù)上下文有不同的含義,請大家注意分辨。 在本文中,使用中文“瀏覽器會話期間”來表達(dá)含義①,使用“session機制”來表達(dá)含義④,使用“session”表達(dá)含義⑤,使用具體的“HttpSession”來表達(dá)含義⑥ 二、HTTP協(xié)議與狀態(tài)保持 HTTP協(xié)議本身是無狀態(tài)的,這與HTTP協(xié)議本來的目的是相符的,客戶端只需要簡單的向服務(wù)器請求下載某些文件,無論是客戶端還是服務(wù)器都沒有必要紀(jì)錄彼此過去的行為,每一次請求之間都是獨立的,好比一個顧客和一個自動售貨機或者一個普通的(非會員制)大賣場之間的關(guān)系一樣。 然而聰明(或者貪心?)的人們很快發(fā)現(xiàn)如果能夠提供一些按需生成的動態(tài)信息會使web變得更加有用,就像給有線電視加上點播功能一樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為,另一方面在服務(wù)器端則出現(xiàn)了CGI規(guī)范以響應(yīng)客戶端的動態(tài)請求,作為傳輸載體的HTTP協(xié)議也添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作出的努力。至于后來出現(xiàn)的session機制則是又一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案。 讓我們用幾個例子來描述一下cookie和session機制之間的區(qū)別與聯(lián)系。筆者曾經(jīng)常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優(yōu)惠,然而一次性消費5杯咖啡的機會微乎其微,這時就需要某種方式來紀(jì)錄某位顧客的消費數(shù)量。想象一下其實也無外乎下面的幾種方案: 1、該店的店員很厲害,能記住每位顧客的消費數(shù)量,只要顧客一走進(jìn)咖啡店,店員就知道該怎么對待了。這種做法就是協(xié)議本身支持狀態(tài)。 2、發(fā)給顧客一張卡片,上面記錄著消費的數(shù)量,一般還有個有效期限。每次消費時,如果顧客出示這張卡片,則此次消費就會與以前或以后的消費相聯(lián)系起來。這種做法就是在客戶端保持狀態(tài)。 3、發(fā)給顧客一張會員卡,除了卡號之外什么信息也不紀(jì)錄,每次消費時,如果顧客出示該卡片,則店員在店里的紀(jì)錄本上找到這個卡號對應(yīng)的紀(jì)錄添加一些消費信息。這種做法就是在服務(wù)器端保持狀態(tài)。 由于HTTP協(xié)議是無狀態(tài)的,而出于種種考慮也不希望使之成為有狀態(tài)的,因此,后面兩種方案就成為現(xiàn)實的選擇。具體來說cookie機制采用的是在客戶端保持狀態(tài)的方案,而session機制采用的是在服務(wù)器端保持狀態(tài)的方案。同時我們也看到,由于采用服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個標(biāo)識,所以session機制可能需要借助于cookie機制來達(dá)到保存標(biāo)識的目的,但實際上它還有其他選擇。 三、理解cookie機制 cookie機制的基本原理就如上面的例子一樣簡單,但是還有幾個問題需要解決:“會員卡”如何分發(fā);“會員卡”的內(nèi)容;以及客戶如何使用“會員卡”。 正統(tǒng)的cookie分發(fā)是通過擴(kuò)展HTTP協(xié)議來實現(xiàn)的,服務(wù)器通過在HTTP的響應(yīng)頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應(yīng)的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。 而cookie的使用是由瀏覽器按照一定的原則在后臺自動發(fā)送給服務(wù)器的。瀏覽器檢查所有存儲的cookie,如果某個cookie所聲明的作用范圍大于等于將要請求的資源所在的位置,則把該cookie附在請求資源的HTTP請求頭上發(fā)送給服務(wù)器。意思是麥當(dāng)勞的會員卡只能在麥當(dāng)勞的店里出示,如果某家分店還發(fā)行了自己的會員卡,那么進(jìn)這家店的時候除了要出示麥當(dāng)勞的會員卡,還要出示這家店的會員卡。 cookie的內(nèi)容主要包括:名字,值,過期時間,路徑和域。 其中域可以指定某一個域比如.google.com,相當(dāng)于總店招牌,比如寶潔公司,也可以指定一個域下的具體某臺機器比如www.google.com或者froogle.google.com,可以用飄柔來做比。 路徑就是跟在域名后面的URL路徑,比如/或者/foo等等,可以用某飄柔專柜做比。 路徑與域合在一起就構(gòu)成了cookie的作用范圍。 如果不設(shè)置過期時間,則表示這個cookie的生命期為瀏覽器會話期間,只要關(guān)閉瀏覽器窗口,cookie就消失了。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里,當(dāng)然這種行為并不是規(guī)范規(guī)定的。如果設(shè)置了過期時間,瀏覽器就會把cookie保存到硬盤上,關(guān)閉后再次打開瀏覽器,這些cookie仍然有效直到超過設(shè)定的過期時間。 存儲在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享,比如兩個IE窗口。而對于保存在內(nèi)存里的cookie,不同的瀏覽器有不同的處理方式。對于IE,在一個打開的窗口上按Ctrl-N(或者從文件菜單)打開的窗口可以與原窗口共享,而使用其他方式新開的IE進(jìn)程則不能共享已經(jīng)打開的窗口的內(nèi)存cookie;對于Mozilla Firefox0.8,所有的進(jìn)程和標(biāo)簽頁都可以共享同樣的cookie。一般來說是用javascript的window.open打開的窗口會與原窗口共享內(nèi)存cookie。瀏覽器對于會話cookie的這種只認(rèn)cookie不認(rèn)人的處理方式經(jīng)常給采用session機制的web應(yīng)用程序開發(fā)者造成很大的困擾。 下面就是一個goolge設(shè)置cookie的響應(yīng)頭的例子 HTTP/1.1 302 Found 這是使用HTTPLook這個HTTP Sniffer軟件來俘獲的HTTP通訊紀(jì)錄的一部分 使用Firefox可以很容易的觀察現(xiàn)有的cookie的值 使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。 這是一個詢問接受cookie的對話框。 四、理解session機制 session機制是一種服務(wù)器端的機制,服務(wù)器使用一種類似于散列表的結(jié)構(gòu)(也可能就是使用散列表)來保存信息。 當(dāng)程序需要為某個客戶端的請求創(chuàng)建一個session的時候,服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標(biāo)識 - 稱為session id,如果已包含一個session id則說明以前已經(jīng)為此客戶端創(chuàng)建過session,服務(wù)器就按照session id把這個session檢索出來使用(如果檢索不到,可能會新建一個),如果客戶端請求不包含session id,則為此客戶端創(chuàng)建一個session并且生成一個與此session相關(guān)聯(lián)的session id,session id的值應(yīng)該是一個既不會重復(fù),又不容易被找到規(guī)律以仿造的字符串,這個session id將被在本次響應(yīng)中返回給客戶端保存。 保存這個session id的方式可以采用cookie,這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標(biāo)識發(fā)揮給服務(wù)器。一般這個cookie的名字都是類似于SEEESIONID,而。比如weblogic對于web應(yīng)用程序生成的cookie,JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764,它的名字就是JSESSIONID。 由于cookie可以被人為的禁止,必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞回服務(wù)器。經(jīng)常被使用的一種技術(shù)叫做URL重寫,就是把session id直接附加在URL路徑的后面,附加方式也有兩種,一種是作為URL路徑的附加信息,表現(xiàn)形式為http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764另一種是作為查詢字符串附加在URL后面,表現(xiàn)形式為http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 為了在整個交互過程中始終保持狀態(tài),就必須在每個客戶端可能請求的路徑后面都包含這個session id。 另一種技術(shù)叫做表單隱藏字段。就是服務(wù)器會自動修改表單,添加一個隱藏字段,以便在表單提交時能夠把session id傳遞回服務(wù)器。比如下面的表單
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html
瀏覽器在再次訪問goolge的資源時自動向外發(fā)送cookie
IE也可以設(shè)置在接受cookie前詢問
這兩種方式對于用戶來說是沒有區(qū)別的,只是服務(wù)器在解析的時候處理的方式不同,采用第一種方式也有利于把session id的信息和正常程序參數(shù)區(qū)分開來。
在被傳遞給客戶端之前將被改寫成
這種技術(shù)現(xiàn)在已較少應(yīng)用,筆者接觸過的很古老的iPlanet6(SunONE應(yīng)用服務(wù)器的前身)就使用了這種技術(shù)。實際上這種技術(shù)可以簡單的用對action應(yīng)用URL重寫來代替。
在談?wù)搒ession機制的時候,常常聽到這樣一種誤解“只要關(guān)閉瀏覽器,session就消失了”。其實可以想象一下會員卡的例子,除非顧客主動對店家提出銷卡,否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的,除非程序通知服務(wù)器刪除一個session,否則服務(wù)器會一直保留,程序一般都是在用戶做log off的時候發(fā)個指令去刪除session。然而瀏覽器從來不會主動在關(guān)閉之前通知服務(wù)器它將要關(guān)閉,因此服務(wù)器根本不會有機會知道瀏覽器已經(jīng)關(guān)閉,之所以會有這種錯覺,是大部分session機制都使用會話cookie來保存session id,而關(guān)閉瀏覽器后這個session id就消失了,再次連接服務(wù)器時也就無法找到原來的session。如果服務(wù)器設(shè)置的cookie被保存到硬盤上,或者使用某種手段改寫瀏覽器發(fā)出的HTTP請求頭,把原來的session id發(fā)送給服務(wù)器,則再次打開瀏覽器仍然能夠找到原來的session。
恰恰是由于關(guān)閉瀏覽器不會導(dǎo)致session被刪除,迫使服務(wù)器為seesion設(shè)置了一個失效時間,當(dāng)距離客戶端上一次使用session的時間超過這個失效時間時,服務(wù)器就可以認(rèn)為客戶端已經(jīng)停止了活動,才會把session刪除以節(jié)省存儲空間。
五、理解javax.servlet.http.HttpSession
HttpSession是Java平臺對session機制的實現(xiàn)規(guī)范,因為它僅僅是個接口,具體到每個web應(yīng)用服務(wù)器的提供商,除了對規(guī)范支持之外,仍然會有一些規(guī)范里沒有規(guī)定的細(xì)微差異。這里我們以BEA的Weblogic Server8.1作為例子來演示。
首先,Weblogic Server提供了一系列的參數(shù)來控制它的HttpSession的實現(xiàn),包括使用cookie的開關(guān)選項,使用URL重寫的開關(guān)選項,session持久化的設(shè)置,session失效時間的設(shè)置,以及針對cookie的各種設(shè)置,比如設(shè)置cookie的名字、路徑、域,cookie的生存時間等。
一般情況下,session都是存儲在內(nèi)存里,當(dāng)服務(wù)器進(jìn)程被停止或者重啟的時候,內(nèi)存里的session也會被清空,如果設(shè)置了session的持久化特性,服務(wù)器就會把session保存到硬盤上,當(dāng)服務(wù)器進(jìn)程重新啟動或這些信息將能夠被再次使用,Weblogic Server支持的持久性方式包括文件、數(shù)據(jù)庫、客戶端cookie保存和復(fù)制。
復(fù)制嚴(yán)格說來不算持久化保存,因為session實際上還是保存在內(nèi)存里,不過同樣的信息被復(fù)制到各個cluster內(nèi)的服務(wù)器進(jìn)程中,這樣即使某個服務(wù)器進(jìn)程停止工作也仍然可以從其他進(jìn)程中取得session。
cookie生存時間的設(shè)置則會影響瀏覽器生成的cookie是否是一個會話cookie。默認(rèn)是使用會話cookie。有興趣的可以用它來試驗我們在第四節(jié)里提到的那個誤解。
cookie的路徑對于web應(yīng)用程序來說是一個非常重要的選項,Weblogic Server對這個選項的默認(rèn)處理方式使得它與其他服務(wù)器有明顯的區(qū)別。后面我們會專題討論。
關(guān)于session的設(shè)置參考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869
六、HttpSession常見問題
(在本小節(jié)中session的含義為⑤和⑥的混合)
1、session在何時被創(chuàng)建
一個常見的誤解是以為session在有客戶端訪問時就被創(chuàng)建,然而事實是直到某server端程序調(diào)用HttpServletRequest.getSession(true)這樣的語句時才被創(chuàng)建,注意如果JSP沒有顯示的使用 <%@page session="false"%>關(guān)閉session,則JSP文件在編譯成Servlet時將會自動加上這樣一條語句HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的session對象的來歷。
由于session會消耗內(nèi)存資源,因此,如果不打算使用session,應(yīng)該在所有的JSP中關(guān)閉它。
2、session何時被刪除
綜合前面的討論,session在下列情況下被刪除a.程序調(diào)用HttpSession.invalidate();或b.距離上一次收到客戶端發(fā)送的session id時間間隔超過了session的超時設(shè)置;或c.服務(wù)器進(jìn)程被停止(非持久session)
3、如何做到在瀏覽器關(guān)閉時刪除session
嚴(yán)格的講,做不到這一點。可以做一點努力的辦法是在所有的客戶端頁面里使用javascript代碼window.oncolose來監(jiān)視瀏覽器的關(guān)閉動作,然后向服務(wù)器發(fā)送一個請求來刪除session。但是對于瀏覽器崩潰或者強行殺死進(jìn)程這些非常規(guī)手段仍然無能為力。
4、有個HttpSessionListener是怎么回事
你可以創(chuàng)建這樣的listener去監(jiān)控session的創(chuàng)建和銷毀事件,使得在發(fā)生這樣的事件時你可以做一些相應(yīng)的工作。注意是session的創(chuàng)建和銷毀動作觸發(fā)listener,而不是相反。類似的與HttpSession有關(guān)的listener還有HttpSessionBindingListener,HttpSessionActivationListener和HttpSessionAttributeListener。
5、存放在session中的對象必須是可序列化的嗎
不是必需的。要求對象可序列化只是為了session能夠在集群中被復(fù)制或者能夠持久保存或者在必要時server能夠暫時把session交換出內(nèi)存。在Weblogic Server的session中放置一個不可序列化的對象在控制臺上會收到一個警告。我所用過的某個iPlanet版本如果session中有不可序列化的對象,在session銷毀時會有一個Exception,很奇怪。
6、如何才能正確的應(yīng)付客戶端禁止cookie的可能性
對所有的URL使用URL重寫,包括超鏈接,form的action,和重定向的URL,具體做法參見[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
7、開兩個瀏覽器窗口訪問應(yīng)用程序會使用同一個session還是不同的session
參見第三小節(jié)對cookie的討論,對session來說是只認(rèn)id不認(rèn)人,因此不同的瀏覽器,不同的窗口打開方式以及不同的cookie存儲方式都會對這個問題的答案有影響。
8、如何防止用戶打開兩個瀏覽器窗口操作導(dǎo)致的session混亂
這個問題與防止表單多次提交是類似的,可以通過設(shè)置客戶端的令牌來解決。就是在服務(wù)器每次生成一個不同的id返回給客戶端,同時保存在session里,客戶端提交表單時必須把這個id也返回服務(wù)器,程序首先比較返回的id與保存在session里的值是否一致,如果不一致則說明本次操作已經(jīng)被提交過了。可以參看《J2EE核心模式》關(guān)于表示層模式的部分。需要注意的是對于使用javascript window.open打開的窗口,一般不設(shè)置這個id,或者使用單獨的id,以防主窗口無法操作,建議不要再window.open打開的窗口里做修改操作,這樣就可以不用設(shè)置。
9、為什么在Weblogic Server中改變session的值后要重新調(diào)用一次session.setValue
做這個動作主要是為了在集群環(huán)境中提示W(wǎng)eblogic Server session中的值發(fā)生了改變,需要向其他服務(wù)器進(jìn)程復(fù)制新的session值。
10、為什么session不見了
排除session正常失效的因素之外,服務(wù)器本身的可能性應(yīng)該是微乎其微的,雖然筆者在iPlanet6SP1加若干補丁的Solaris版本上倒也遇到過;瀏覽器插件的可能性次之,筆者也遇到過3721插件造成的問題;理論上防火墻或者代理服務(wù)器在cookie處理上也有可能會出現(xiàn)問題。
出現(xiàn)這一問題的大部分原因都是程序的錯誤,最常見的就是在一個應(yīng)用程序中去訪問另外一個應(yīng)用程序。我們在下一節(jié)討論這個問題。
七、跨應(yīng)用程序的session共享
常常有這樣的情況,一個大項目被分割成若干小項目開發(fā),為了能夠互不干擾,要求每個小項目作為一個單獨的web應(yīng)用程序開發(fā),可是到了最后突然發(fā)現(xiàn)某幾個小項目之間需要共享一些信息,或者想使用session來實現(xiàn)SSO(single sign on),在session中保存login的用戶信息,最自然的要求是應(yīng)用程序間能夠訪問彼此的session。
然而按照Servlet規(guī)范,session的作用范圍應(yīng)該僅僅限于當(dāng)前應(yīng)用程序下,不同的應(yīng)用程序之間是不能夠互相訪問對方的session的。各個應(yīng)用服務(wù)器從實際效果上都遵守了這一規(guī)范,但是實現(xiàn)的細(xì)節(jié)卻可能各有不同,因此解決跨應(yīng)用程序session共享的方法也各不相同。
首先來看一下Tomcat是如何實現(xiàn)web應(yīng)用程序之間session的隔離的,從Tomcat設(shè)置的cookie路徑來看,它對不同的應(yīng)用程序設(shè)置的cookie路徑是不同的,這樣不同的應(yīng)用程序所用的session id是不同的,因此即使在同一個瀏覽器窗口里訪問不同的應(yīng)用程序,發(fā)送給服務(wù)器的session id也可以是不同的。
根據(jù)這個特性,我們可以推測Tomcat中session的內(nèi)存結(jié)構(gòu)大致如下。
筆者以前用過的iPlanet也采用的是同樣的方式,估計SunONE與iPlanet之間不會有太大的差別。對于這種方式的服務(wù)器,解決的思路很簡單,實際實行起來也不難。要么讓所有的應(yīng)用程序共享一個session id,要么讓應(yīng)用程序能夠獲得其他應(yīng)用程序的session id。
iPlanet中有一種很簡單的方法來實現(xiàn)共享一個session id,那就是把各個應(yīng)用程序的cookie路徑都設(shè)為/(實際上應(yīng)該是/NASApp,對于應(yīng)用程序來講它的作用相當(dāng)于根)。
需要注意的是,操作共享的session應(yīng)該遵循一些編程約定,比如在session attribute名字的前面加上應(yīng)用程序的前綴,使得setAttribute("name", "neo")變成setAttribute("app1.name", "neo"),以防止命名空間沖突,導(dǎo)致互相覆蓋。
在Tomcat中則沒有這么方便的選擇。在Tomcat版本3上,我們還可以有一些手段來共享session。對于版本4以上的Tomcat,目前筆者尚未發(fā)現(xiàn)簡單的辦法。只能借助于第三方的力量,比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie,URL參數(shù)或者隱藏字段等手段。
我們再看一下Weblogic Server是如何處理session的。
從截屏畫面上可以看到Weblogic Server對所有的應(yīng)用程序設(shè)置的cookie的路徑都是/,這是不是意味著在Weblogic Server中默認(rèn)的就可以共享session了呢?然而一個小實驗即可證明即使不同的應(yīng)用程序使用的是同一個session,各個應(yīng)用程序仍然只能訪問自己所設(shè)置的那些屬性。這說明Weblogic Server中的session的內(nèi)存結(jié)構(gòu)可能如下
對于這樣一種結(jié)構(gòu),在session機制本身上來解決session共享的問題應(yīng)該是不可能的了。除了借助于第三方的力量,比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie,URL參數(shù)或者隱藏字段等手段,還有一種較為方便的做法,就是把一個應(yīng)用程序的session放到ServletContext中,這樣另外一個應(yīng)用程序就可以從ServletContext中取得前一個應(yīng)用程序的引用。示例代碼如下,
應(yīng)用程序A
context.setAttribute("appA", session);
應(yīng)用程序B
contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");
值得注意的是這種用法不可移植,因為根據(jù)ServletContext的JavaDoc,應(yīng)用服務(wù)器可以處于安全的原因?qū)τ赾ontext.getContext("/appA");返回空值,以上做法在Weblogic Server 8.1中通過。
那么Weblogic Server為什么要把所有的應(yīng)用程序的cookie路徑都設(shè)為/呢?原來是為了SSO,凡是共享這個session的應(yīng)用程序都可以共享認(rèn)證的信息。一個簡單的實驗就可以證明這一點,修改首先登錄的那個應(yīng)用程序的描述符weblogic.xml,把cookie路徑修改為/appA訪問另外一個應(yīng)用程序會重新要求登錄,即使是反過來,先訪問cookie路徑為/的應(yīng)用程序,再訪問修改過路徑的這個,雖然不再提示登錄,但是登錄的用戶信息也會丟失。注意做這個實驗時認(rèn)證方式應(yīng)該使用FORM,因為瀏覽器和web服務(wù)器對basic認(rèn)證方式有其他的處理方式,第二次請求的認(rèn)證不是通過session來實現(xiàn)的。具體請參看[7] secion 14.8 Authorization,你可以修改所附的示例程序來做這些試驗。
八、總結(jié)
session機制本身并不復(fù)雜,然而其實現(xiàn)和配置上的靈活性卻使得具體情況復(fù)雜多變。這也要求我們不能把僅僅某一次的經(jīng)驗或者某一個瀏覽器,服務(wù)器的經(jīng)驗當(dāng)作普遍適用的經(jīng)驗,而是始終需要具體情況具體分析。
NOKIA的*#92702689#的詳解以前裝過sql server,后來刪掉。現(xiàn)在重裝,卻出現(xiàn)“以前的某個程序安裝已在安裝計算機上創(chuàng)建掛起的文件操作。運行安裝程序之前必須重新啟動計算機”錯誤。無法進(jìn)行下去。
參考網(wǎng)上資料,總算搞定。步驟是:
1)添加/刪除程序中徹底刪除sql server。
2)將沒有刪除的sql server目錄也刪除掉。
3)打開注冊表編輯器,在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager中找到PendingFileRenameOperations項目,并刪除它。這樣就可以清除安裝暫掛項目。
4)刪除注冊表中跟sql server相關(guān)的鍵。
其實估計只要做第3步就可以搞定,這樣就可以清除安裝暫掛項目。自己是先走了1,2,4,最后做了3才搞定。所以估計3才是最關(guān)鍵的。
ME too
前兩天要把我們信息平臺上的tomcat4加為服務(wù),
剛一開始就想先遷移到tomcat5上可是遷移以后數(shù)據(jù)庫總是聯(lián)不上,郁悶了好久。
后來又從網(wǎng)上找直接把tomcat4加為服務(wù)的腳本,嘗試了幾次,總是找不到tomcat的目錄,原來批處理文件里面不識別空格,把文件名改了下,服務(wù)算是加上了,可啟動時卻總是出錯誤,又重新裝了一次tomcat4.1.3,發(fā)現(xiàn)裝完以后在 /bin的文件夾里,根本就沒有tomcat.exe,著實有些郁悶,看來原來那個tomcat.exe肯定是從tomcat5里面拷過來的。不經(jīng)意間又裝了一遍tomcat4.1.3,發(fā)現(xiàn)有一個選項(NT service xp/2000;only)郁悶啊,這不是直接就可以加為服務(wù)嗎,暈死了過去。。。。
這說明我還是太粗心了,裝過那么多回tomcat,也想過這個ntservice,怎么就記過這就是加成服務(wù)的呢
,我說網(wǎng)上相關(guān)的東西怎么這么少,原來是apahce已經(jīng)帶了這個功能。
把以下代碼粘貼到首頁中,就可以從counter.txt中讀取訪問量。
一定要注意路徑的問題,剛開始直接用counter.txt,結(jié)果總是找不到文件,而且用絕對路徑也不行,
但是用/counter.txt就沒有問題
<%!
int number=0;
synchronized void countPeople(){
if(number==0){
try{
FileInputStream in=new FileInputStream("/counter.txt");
DataInputStream dataIn=new DataInputStream(in);
number=dataIn.readInt();
number++;
in.close();
dataIn.close();
}catch(FileNotFoundException e){
number++;
try{
FileOutputStream out=new FileOutputStream("/counter.txt");
DataOutputStream dataOut=new DataOutputStream(out);
dataOut.writeInt(number);
out.close();
dataOut.close();
}catch(IOException ffe){
System.out.print(ffe);
}
}catch(IOException ee){
System.out.println(ee);
}
}else{
number++;
try{
FileOutputStream out=new FileOutputStream("/counter.txt");
DataOutputStream dataOut=new DataOutputStream(out);
dataOut.writeInt(number);
out.close();
dataOut.close();
}catch(FileNotFoundException e){
System.out.println(e);
}
catch(IOException e){
System.out.println(e);
}
}
}
%>
<% countPeople();%>
您的人格類型是: ISFJ(內(nèi)向,感覺,情感,判斷) | |
|
<form action="submit_1.html" method=post>
<input type=image src="exa.gif" name="sub1">
</form>
就是這簡單
log4j.rootLogger=DEBUG,stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %5p (%F:%L) - %m%n |
<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> <property name="dataSource"><ref bean="dataSource"/></property> <property name="mappingResources"> <list> <value>User.hbm.xml</value> 錯,改為: <value>com/yz/spring/domain/User.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect"> net.sf.hibernate.dialect.MySQLDialect </prop> <prop key="hibernate.show_sql">true</prop> </props> </property> </bean> |
public class PostManageImpl extends BaseManage implements PostManage { private PostDAO dao = null; public void setPostDAO(PostDAO postDAO){ this.dao = postDAO; } } |
<bean id="postManage" parent="txProxyTemplate"> <property name="target"> <bean class="com.yz.spring.service.implement.PostManageImpl"> <property name="postDAO"><ref bean="postDAO"/></property> 對 <property name="dao"><ref bean="postDAO"/></property> 錯 </bean> </property> </bean> |
<bean id="txProxyTemplate" abstract="true" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"><ref bean="transactionManager"/></property> <property name="transactionAttributes"> <props> <prop key="save*">PROPAGATION_REQUIRED</prop> <prop key="remove*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_REQUIRED</prop> </props> </property> </bean> <bean id="userManage" parent="txProxyTemplate"> <property name="target"> <bean class="com.yz.spring.service.implement.UserManageImpl"> <property name="userDAO"><ref bean="userDAO"/></property> </bean> </property> </bean> |
String[] paths = {"com/yz/spring/dao/hibernate/applicationContext-hibernate.xml", "com/yz/spring/service/applicationContext-service.xml"}; ctx = new ClassPathXmlApplicationContext(paths); |
<servlet> <servlet-name>context</servlet-name> <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/applicationContext-hibernate.xml</param-value> <param-value>/WEB-INF/applicationContext-service.xml</param-value> </context-param> |
<context-param> <param-name>log4jConfigLocation</param-name> <param-value>/WEB-INF/log4j.properties</param-value> </context-param> |
Expert One on one J2EE Design and Development Expert One on one J2EE Development Without EJB |
http://www.martinfowler.com/articles/injection.html |
http://www.jactiongroup.net/reference/html/index.html(中文版,未全部翻譯) |
abstract class和interface是Java語言中對于抽象類定義進(jìn)行支持的兩種機制,正是由于這兩種機制的存在,才賦予了Java強大的面向?qū)ο竽芰Αbstract class和interface之間在對于抽象類定義的支持方面具有很大的相似性,甚至可以相互替換,因此很多開發(fā)者在進(jìn)行抽象類定義時對于abstract class和interface的選擇顯得比較隨意。
其實,兩者之間還是有很大的區(qū)別的,對于它們的選擇甚至反映出對于問題領(lǐng)域本質(zhì)的理解、對于設(shè)計意圖的理解是否正確、合理。本文將對它們之間的區(qū)別進(jìn)行一番剖析,試圖給開發(fā)者提供一個在二者之間進(jìn)行選擇的依據(jù)。
一、理解抽象類
abstract class和interface在Java語言中都是用來進(jìn)行抽象類(本文中的抽象類并非從abstract class翻譯而來,它表示的是一個抽象體,而abstract class為Java語言中用于定義抽象類的一種方法,請讀者注意區(qū)分)定義的,那么什么是抽象類,使用抽象類能為我們帶來什么好處呢?
在面向?qū)ο蟮母拍钪校覀冎浪械膶ο蠖际峭ㄟ^類來描繪的,但是反過來卻不是這樣。并不是所有的類都是用來描繪對象的,如果一個類中沒有包含足夠的信息來描繪一個具體的對象,這樣的類就是抽象類。抽象類往往用來表征我們在對問題領(lǐng)域進(jìn)行分析、設(shè)計中得出的抽象概念,是對一系列看上去不同,但是本質(zhì)上相同的具體概念的抽象。
比如:如果我們進(jìn)行一個圖形編輯軟件的開發(fā),就會發(fā)現(xiàn)問題領(lǐng)域存在著圓、三角形這樣一些具體概念,它們是不同的,但是它們又都屬于形狀這樣一個概念,形狀這個概念在問題領(lǐng)域是不存在的,它就是一個抽象概念。正是因為抽象的概念在問題領(lǐng)域沒有對應(yīng)的具體概念,所以用以表征抽象概念的抽象類是不能夠?qū)嵗摹?BR>在面向?qū)ο箢I(lǐng)域,抽象類主要用來進(jìn)行類型隱藏。我們可以構(gòu)造出一個固定的一組行為的抽象描述,但是這組行為卻能夠有任意個可能的具體實現(xiàn)方式。這個抽象描述就是抽象類,而這一組任意個可能的具體實現(xiàn)則表現(xiàn)為所有可能的派生類。模塊可以操作一個抽象體。由于模塊依賴于一個固定的抽象體,因此它可以是不允許修改的;同時,通過從這個抽象體派生,也可擴(kuò)展此模塊的行為功能。熟悉OCP的讀者一定知道,為了能夠?qū)崿F(xiàn)面向?qū)ο笤O(shè)計的一個最核心的原則OCP(Open-Closed Principle),抽象類是其中的關(guān)鍵所在。
二、從語法定義層面看abstract class和interface
在語法層面,Java語言對于abstract class和interface給出了不同的定義方式,下面以定義一個名為Demo的抽象類為例來說明這種不同。使用abstract class的方式定義Demo抽象類的方式如下:
|
使用interface的方式定義Demo抽象類的方式如下:
|
在abstract class方式中,Demo可以有自己的數(shù)據(jù)成員,也可以有非abstarct的成員方法,而在interface方式的實現(xiàn)中,Demo只能夠有靜態(tài)的不能被修改的數(shù)據(jù)成員(也就是必須是static final的,不過在interface中一般不定義數(shù)據(jù)成員),所有的成員方法都是abstract的。從某種意義上說,interface是一種特殊形式的abstract class。
從編程的角度來看,abstract class和interface都可以用來實現(xiàn)"design by contract"的思想。但是在具體的使用上面還是有一些區(qū)別的。
首先,abstract class在Java語言中表示的是一種繼承關(guān)系,一個類只能使用一次繼承關(guān)系。但是,一個類卻可以實現(xiàn)多個interface。也許,這是Java語言的設(shè)計者在考慮Java對于多重繼承的支持方面的一種折中考慮吧。
其次,在abstract class的定義中,我們可以賦予方法的默認(rèn)行為。但是在interface的定義中,方法卻不能擁有默認(rèn)行為,為了繞過這個限制,必須使用委托,但是這會 增加一些復(fù)雜性,有時會造成很大的麻煩。
在抽象類中不能定義默認(rèn)行為還存在另一個比較嚴(yán)重的問題,那就是可能會造成維護(hù)上的麻煩。因為如果后來想修改類的界面(一般通過abstract class或者interface來表示)以適應(yīng)新的情況(比如,添加新的方法或者給已用的方法中添加新的參數(shù))時,就會非常的麻煩,可能要花費很多的時間(對于派生類很多的情況,尤為如此)。但是如果界面是通過abstract class來實現(xiàn)的,那么可能就只需要修改定義在abstract class中的默認(rèn)行為就可以了。
同樣,如果不能在抽象類中定義默認(rèn)行為,就會導(dǎo)致同樣的方法實現(xiàn)出現(xiàn)在該抽象類的每一個派生類中,違反了"one rule,one place"原則,造成代碼重復(fù),同樣不利于以后的維護(hù)。因此,在abstract class和interface間進(jìn)行選擇時要非常的小心。
三、從設(shè)計理念層面看abstract class和interface
上面主要從語法定義和編程的角度論述了abstract class和interface的區(qū)別,這些層面的區(qū)別是比較低層次的、非本質(zhì)的。本文將從另一個層面:abstract class和interface所反映出的設(shè)計理念,來分析一下二者的區(qū)別。作者認(rèn)為,從這個層面進(jìn)行分析才能理解二者概念的本質(zhì)所在。
前面已經(jīng)提到過,abstarct class在Java語言中體現(xiàn)了一種繼承關(guān)系,要想使得繼承關(guān)系合理,父類和派生類之間必須存在"is a"關(guān)系,即父類和派生類在概念本質(zhì)上應(yīng)該是相同的。對于interface 來說則不然,并不要求interface的實現(xiàn)者和interface定義在概念本質(zhì)上是一致的,僅僅是實現(xiàn)了interface定義的契約而已。為了使論述便于理解,下面將通過一個簡單的實例進(jìn)行說明。
考慮這樣一個例子,假設(shè)在我們的問題領(lǐng)域中有一個關(guān)于Door的抽象概念,該Door具有執(zhí)行兩個動作open和close,此時我們可以通過abstract class或者interface來定義一個表示該抽象概念的類型,定義方式分別如下所示:
|
其他具體的Door類型可以extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來好像使用abstract class和interface沒有大的區(qū)別。
如果現(xiàn)在要求Door還要具有報警的功能。我們該如何設(shè)計針對該例子的類結(jié)構(gòu)呢(在本例中,主要是為了展示abstract class和interface反映在設(shè)計理念上的區(qū)別,其他方面無關(guān)的問題都做了簡化或者忽略)下面將羅列出可能的解決方案,并從設(shè)計理念層面對這些不同的方案進(jìn)行分析。
解決方案一:
簡單的在Door的定義中增加一個alarm方法,如下:
|
那么具有報警功能的AlarmDoor的定義方式如下:
|
|
這種實現(xiàn)方式基本上能夠明確的反映出我們對于問題領(lǐng)域的理解,正確的揭示我們的設(shè)計意圖。其實abstract class表示的是"is a"關(guān)系,interface表示的是"like a"關(guān)系,大家在選擇時可以作為一個依據(jù),當(dāng)然這是建立在對問題領(lǐng)域的理解上的,比如:如果我們認(rèn)為AlarmDoor在概念本質(zhì)上是報警器,同時又具有Door的功能,那么上述的定義方式就要反過來了。
abstract class和interface是Java語言中的兩種定義抽象類的方式,它們之間有很大的相似性。但是對于它們的選擇卻又往往反映出對于問題領(lǐng)域中的概念本質(zhì)的理解、對于設(shè)計意圖的反映是否正確、合理,因為它們表現(xiàn)了概念間的不同的關(guān)系(雖然都能夠?qū)崿F(xiàn)需求的功能)。這其實也是語言的一種的慣用法,希望讀者朋友能夠細(xì)細(xì)體會
JBUILDER的光標(biāo)定位不準(zhǔn)確的最佳解決方案是:進(jìn)入%JBUILDER_HOME%/bin目錄下,用寫字板編輯jbuilder.config,把下面的配置加進(jìn)去: |
Ant的簡介:類似make工具,但可以支持多平臺
Ant的安裝:配置ant的準(zhǔn)備工作:ant_home 指Ant的安裝目錄,在path中加入%ant_home%/bin,用于命令行下
運 行ant
Ant的結(jié)構(gòu):主要是通過對build.xml的配置,
Ant內(nèi)置任務(wù): 描述
property 設(shè)置name/value的屬性
mkdir 創(chuàng)建目錄
copy 拷貝
delete 刪除
javac 編繹
war 打包
下面是一個簡單build.xml的示例:
<project name="bookstore" default="about" basedir=".">
<target name="init">
<tstamp/>
<property name="build" value="build" />
<property name="src" value="src" />
<property environment="myenv" />
<property name="servletpath" value="${myenv.CATALINA_HOME}/common/lib/servlet-api.jar" />
<property name="mysqlpath" value="WEB-INF/lib/mysqldriver.jar" />
<mkdir dir="${build}" />
<mkdir dir="${build}\WEB-INF" />
<mkdir dir="${build}\WEB-INF\classes" />
<copy todir="${build}" >
<fileset dir="${basedir}" >
<include name="*.jsp" />
<include name="*.bmp" />
<include name="WEB-INF/**" />
<exclude name="build.xml" />
</fileset>
</copy>
</target>
<target name="compile" depends="init">
<javac srcdir="${src}"
destdir="${build}/WEB-INF/classes"
classpath="${servletpath}:${mysqlpath}">
</javac>
</target>
<target name="bookstorewar" depends="compile">
<war warfile="${build}/bookstore.war" webxml="${build}/WEB-INF/web.xml">
<lib dir="${build}/WEB-INF/lib"/>
<classes dir="${build}/WEB-INF/classes"/>
<fileset dir="${build}"/>
</war>
</target>
<target name="about" >
<echo>
This build.xml file contains targets
for building bookstore web application
</echo>
</target>
</project>
從示例我們看出來,整個xml是一個project,project下有幾個為init,compile,的target
運行時首先在這個目錄下打開dos窗口,以這個xml為準(zhǔn),如果你只運行ant那么只會輸出echo中的內(nèi)容
因為project的default是about; 如果運行ant complie 它會執(zhí)行兩個target: init 和complie,因為complie是依靠init
的。
用了以后發(fā)現(xiàn)ant 原來很簡單,當(dāng)然現(xiàn)在只是學(xué)了個皮毛而已。
RMI,遠(yuǎn)程方法調(diào)用(Remote Method Invocation)是Enterprise JavaBeans的支柱,是建立分布式Java應(yīng)用程序的方便途徑。RMI是非常容易使用的,但是它非常的強大。
RMI的基礎(chǔ)是接口,RMI構(gòu)架基于一個重要的原理:定義接口和定義接口的具體實現(xiàn)是分開的。下面我們通過具體的例子,建立一個簡單的遠(yuǎn)程計算服務(wù)和使用它的客戶程序
一個正常工作的RMI系統(tǒng)由下面幾個部分組成:
● 遠(yuǎn)程服務(wù)的接口定義
● 遠(yuǎn)程服務(wù)接口的具體實現(xiàn)
● 樁(Stub)和框架(Skeleton)文件
● 一個運行遠(yuǎn)程服務(wù)的服務(wù)器
● 一個RMI命名服務(wù),它允許客戶端去發(fā)現(xiàn)這個遠(yuǎn)程服務(wù)
● 類文件的提供者(一個HTTP或者FTP服務(wù)器)
● 一個需要這個遠(yuǎn)程服務(wù)的客戶端程序
下面我們一步一步建立一個簡單的RMI系統(tǒng)。首先在你的機器里建立一個新的文件夾,以便放置我們創(chuàng)建的文件,為了簡單起見,我們只使用一個文件夾存放客戶端和服務(wù)端代碼,并且在同一個目錄下運行服務(wù)端和客戶端。
如果所有的RMI文件都已經(jīng)設(shè)計好了,那么你需要下面的幾個步驟去生成你的系統(tǒng):
1、 編寫并且編譯接口的Java代碼
2、 編寫并且編譯接口實現(xiàn)的Java代碼
3、 從接口實現(xiàn)類中生成樁(Stub)和框架(Skeleton)類文件
4、 編寫遠(yuǎn)程服務(wù)的主運行程序
5、 編寫RMI的客戶端程序
6、 安裝并且運行RMI系統(tǒng)
1、 接口
第一步就是建立和編譯服務(wù)接口的Java代碼。這個接口定義了所有的提供遠(yuǎn)程服務(wù)的功能,下面是源程序:
//Calculator.java
//define the interface
import java.rmi.Remote;
public interface Calculator extends Remote
{
public long add(long a, long b)
throws java.rmi.RemoteException;
public long sub(long a, long b)
throws java.rmi.RemoteException;
public long mul(long a, long b)
throws java.rmi.RemoteException;
public long div(long a, long b)
throws java.rmi.RemoteException;
}
注意,這個接口繼承自Remote,每一個定義的方法都必須拋出一個RemoteException異常對象。
建立這個文件,把它存放在剛才的目錄下,并且編譯。
>javac Calculator.java
2、 接口的具體實現(xiàn)
下一步,我們就要寫遠(yuǎn)程服務(wù)的具體實現(xiàn),這是一個CalculatorImpl類文件:
//CalculatorImpl.java
//Implementation
import java.rmi.server.UnicastRemoteObject
public class CalculatorImpl extends UnicastRemoteObject implements Calculator
{
// 這個實現(xiàn)必須有一個顯式的構(gòu)造函數(shù),并且要拋出一個RemoteException異常
public CalculatorImpl()
throws java.rmi.RemoteException {
super();
}
public long add(long a, long b)
throws java.rmi.RemoteException {
return a + b;
}
public long sub(long a, long b)
throws java.rmi.RemoteException {
return a - b;
}
public long mul(long a, long b)
throws java.rmi.RemoteException {
return a * b;
}
public long div(long a, long b)
throws java.rmi.RemoteException {
return a / b;
}
}
同樣的,把這個文件保存在你的目錄里然后編譯他。
這個實現(xiàn)類使用了UnicastRemoteObject去聯(lián)接RMI系統(tǒng)。在我們的例子中,我們是直接的從UnicastRemoteObject這個類上繼承的,事實上并不一定要這樣做,如果一個類不是從UnicastRmeoteObject上繼承,那必須使用它的exportObject()方法去聯(lián)接到RMI。
如果一個類繼承自UnicastRemoteObject,那么它必須提供一個構(gòu)造函數(shù)并且聲明拋出一個RemoteException對象。當(dāng)這個構(gòu)造函數(shù)調(diào)用了super(),它久激活UnicastRemoteObject中的代碼完成RMI的連接和遠(yuǎn)程對象的初始化。
3、 樁(Stubs)和框架(Skeletons)
下一步就是要使用RMI編譯器rmic來生成樁和框架文件,這個編譯運行在遠(yuǎn)程服務(wù)實現(xiàn)類文件上。
>rmic CalculatorImpl
在你的目錄下運行上面的命令,成功執(zhí)行完上面的命令你可以發(fā)現(xiàn)一個Calculator_stub.class文件,如果你是使用的Java2SDK,那么你還可以發(fā)現(xiàn)Calculator_Skel.class文件。
4、 主機服務(wù)器
遠(yuǎn)程RMI服務(wù)必須是在一個服務(wù)器中運行的。CalculatorServer類是一個非常簡單的服務(wù)器。
//CalculatorServer.java
import java.rmi.Naming;
public class CalculatorServer {
public CalculatorServer() {
try {
Calculator c = new CalculatorImpl();
Naming.rebind("rmi://localhost:1099/CalculatorService", c);
} catch (Exception e) {
System.out.println("Trouble: " + e);
}
}
public static void main(String args[]) {
new CalculatorServer();
}
}
建立這個服務(wù)器程序,然后保存到你的目錄下,并且編譯它。
5、 客戶端
客戶端源代碼如下:
//CalculatorClient.java
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.net.MalformedURLException;
import java.rmi.NotBoundException;
public class CalculatorClient {
public static void main(String[] args) {
try {
Calculator c = (Calculator)
Naming.lookup(
"rmi://localhost
/CalculatorService");
System.out.println( c.sub(4, 3) );
System.out.println( c.add(4, 5) );
System.out.println( c.mul(3, 6) );
System.out.println( c.div(9, 3) );
}
catch (MalformedURLException murle) {
System.out.println();
System.out.println(
"MalformedURLException");
System.out.println(murle);
}
catch (RemoteException re) {
System.out.println();
System.out.println(
"RemoteException");
System.out.println(re);
}
catch (NotBoundException nbe) {
System.out.println();
System.out.println(
"NotBoundException");
System.out.println(nbe);
}
catch (
java.lang.ArithmeticException
ae) {
System.out.println();
System.out.println(
"java.lang.ArithmeticException");
System.out.println(ae);
}
}
}
保存這個客戶端程序到你的目錄下(注意這個目錄是一開始建立那個,所有的我們的文件都在那個目錄下),并且編譯他。
6、 運行RMI系統(tǒng)
現(xiàn)在我們建立了所有運行這個簡單RMI系統(tǒng)所需的文件,現(xiàn)在我們終于可以運行這個RMI系統(tǒng)啦!來享受吧。
我們是在命令控制臺下運行這個系統(tǒng)的,你必須開啟三個控制臺窗口,一個運行服務(wù)器,一個運行客戶端,還有一個運行RMIRegistry。
首先運行注冊程序RMIRegistry,你必須在包含你剛寫的類的那么目錄下運行這個注冊程序。
>rmiregistry
好,這個命令成功的話,注冊程序已經(jīng)開始運行了,不要管他,現(xiàn)在切換到另外一個控制臺,在第二個控制臺里,我們運行服務(wù)器CalculatorService,因為RMI的安全機制將在服務(wù)端發(fā)生作用,所以你必須增加一條安全策略。以下是對應(yīng)安全策略的例子
grant {
permission java.security.AllPermission "", "";
};
注意:這是一條最簡單的安全策略,它允許任何人做任何事,對于你的更加關(guān)鍵性的應(yīng)用,你必須指定更加詳細(xì)安全策略。
現(xiàn)在為了運行服務(wù)端,你需要除客戶類(CalculatorClient.class)之外的所有的類文件。確認(rèn)安全策略在policy.txt文件之后,使用如下命令來運行服務(wù)器。
> java -Djava.security.policy=policy.txt CalculatorServer
這個服務(wù)器就開始工作了,把接口的實現(xiàn)加載到內(nèi)存等待客戶端的聯(lián)接。好現(xiàn)在切換到第三個控制臺,啟動我們的客戶端。
為了在其他的機器運行客戶端程序你需要一個遠(yuǎn)程接口(Calculator.class) 和一個stub(CalculatorImpl_Stub.class)。 使用如下命令運行客戶端
prompt> java -Djava.security.policy=policy.txt CalculatorClient
如果所有的這些都成功運行,你應(yīng)該看到下面的輸出:
1
9
18
3
如果你看到了上面的輸出,恭喜你,你成功了,你已經(jīng)成功的創(chuàng)建了一個RMI系統(tǒng),并且使他正確工作了。即使你運行在同一個計算機上,RMI還是使用了你的網(wǎng)絡(luò)堆棧和TCP/IP去進(jìn)行通訊,并且是運行在三個不同的Java虛擬機上。這已經(jīng)是一個完整的RMI系統(tǒng)。
在一個有密碼保護(hù)的Web應(yīng)用中,正確處理用戶退出過程并不僅僅只需調(diào)用HttpSession的invalidate()方法。現(xiàn)在大部分瀏覽器上都有后退和前進(jìn)按鈕,允許用戶后退或前進(jìn)到一個頁面。如果在用戶在退出一個Web應(yīng)用后按了后退按鈕瀏覽器把緩存中的頁面呈現(xiàn)給用戶,這會使用戶產(chǎn)生疑惑,他們會開始擔(dān)心他們的個人數(shù)據(jù)是否安全。許多Web應(yīng)用強迫用戶退出時關(guān)閉整個瀏覽器,這樣,用戶就無法點擊后退按鈕了。還有一些使用javascript,但在某些客戶端瀏覽器這卻不一定起作用。這些解決方案都很笨拙且不能保證在任一情況下100%有效,同時,它也要求用戶有一定的操作經(jīng)驗。
這篇文章以示例闡述了正確解決用戶退出問題的方案。作者Kevin Le首先描述了一個密碼保護(hù)Web應(yīng)用,然后以示例程序解釋問題如何產(chǎn)生并討論解決問題的方案。文章雖然是針對JSP頁面進(jìn)行闡述,但作者所闡述的概念很容易理解切能夠為其他Web技術(shù)所采用。最后作者展示了如何用Jakarta Struts優(yōu)雅地解決這一問題。
大部分Web應(yīng)用不會包含象銀行賬戶或信用卡資料那樣機密的信息,但一旦涉及到敏感數(shù)據(jù),我們就需要提供一類密碼保護(hù)機制。舉例來說,一個工廠中工人通過Web訪問他們的時間安排、進(jìn)入他們的訓(xùn)練課程以及查看他們的薪金等等。此時應(yīng)用SSL(Secure Socket Layer)有點殺雞用牛刀的感覺,但不可否認(rèn),我們又必須為這些應(yīng)用提供密碼保護(hù),否則,工人(也就是Web應(yīng)用的使用者)可以窺探到工廠中其他雇員的私人機密信息。
與上述情形相似的還有位處圖書館、醫(yī)院等公共場所的計算機。在這些地方,許多用戶共同使用幾臺計算機,此時保護(hù)用戶的個人數(shù)據(jù)就顯得至關(guān)重要。設(shè)計良好編寫優(yōu)秀的應(yīng)用對用戶專業(yè)知識的要求少之又少。
我們來看一下現(xiàn)實世界中一個完美的Web應(yīng)用是如何表現(xiàn)的:一個用戶通過瀏覽器訪問一個頁面。Web應(yīng)用展現(xiàn)一個登陸頁面要求用戶輸入有效的驗證信息。用戶輸入了用戶名和密碼。此時我們假設(shè)用戶提供的身份驗證信息是正確的,經(jīng)過了驗證過程,Web應(yīng)用允許用戶瀏覽他有權(quán)訪問的區(qū)域。用戶想退出時,點擊退出按鈕,Web應(yīng)用要求用戶確認(rèn)他是否則真的需要退出,如果用戶確定退出,Session結(jié)束,Web應(yīng)用重新定位到登陸頁面。用戶可以放心的離開而不用擔(dān)心他的信息會泄露。另一個用戶坐到了同一臺電腦前,他點擊后退按鈕,Web應(yīng)用不應(yīng)該出現(xiàn)上一個用戶訪問過的任何一個頁面。事實上,Web應(yīng)用在第二個用戶提供正確的驗證信息之前應(yīng)當(dāng)一直停留在登陸頁面上。
通過示例程序,文章向您闡述了如何在一個Web應(yīng)用中實現(xiàn)這一功能。
JSP示例
為了更為有效地闡述實現(xiàn)方案,本文將從展示一個示例應(yīng)用logoutSampleJSP1中碰到的問題開始。這個示例代表了許多沒有正確解決退出過程的Web應(yīng)用。logoutSampleJSP1包含了下述jsp頁面:login.jsp, home.jsp, secure1.jsp, secure2.jsp, logout.jsp, loginAction.jsp, and logoutAction.jsp。其中頁面home.jsp, secure1.jsp, secure2.jsp, 和logout.jsp是不允許未經(jīng)認(rèn)證的用戶訪問的,也就是說,這些頁面包含了重要信息,在用戶登陸之前或者退出之后都不應(yīng)該出現(xiàn)在瀏覽器中。login.jsp包含了用于用戶輸入用戶名和密碼的form。logout.jsp頁包含了要求用戶確認(rèn)是否退出的form。loginAction.jsp和logoutAction.jsp作為控制器分別包含了登陸和退出代碼。
第二個示例應(yīng)用logoutSampleJSP2展示了如何解決示例logoutSampleJSP1中的問題。然而,第二個應(yīng)用自身也是有疑問的。在特定的情況下,退出問題還是會出現(xiàn)。
第三個示例應(yīng)用logoutSampleJSP3在第二個示例上進(jìn)行了改進(jìn),比較完善地解決了退出問題。
最后一個示例logoutSampleStruts展示了Struts如何優(yōu)美地解決登陸問題。
注意:本文所附示例在最新版本的Microsoft Internet Explorer (IE), Netscape Navigator, Mozilla, FireFox和Avant瀏覽器上測試通過。
Login action
Brian Pontarelli的經(jīng)典文章《J2EE Security: Container Versus Custom》討論了不同的J2EE認(rèn)證途徑。文章同時指出,HTTP協(xié)議和基于form的認(rèn)證并未提供處理用戶退出的機制。因此,解決途徑便是引入自定義的安全實現(xiàn)機制。
自定義的安全認(rèn)證機制普遍采用的方法是從form中獲得用戶輸入的認(rèn)證信息,然后到諸如LDAP (lightweight directory access protocol)或關(guān)系數(shù)據(jù)庫的安全域中進(jìn)行認(rèn)證。如果用戶提供的認(rèn)證信息是有效的,登陸動作往HttpSession對象中注入某個對象。HttpSession存在著注入的對象則表示用戶已經(jīng)登陸。為了方便讀者理解,本文所附的示例只往HttpSession中寫入一個用戶名以表明用戶已經(jīng)登陸。清單1是從loginAction.jsp頁面中節(jié)選的一段代碼以此闡述登陸動作:
Listing 1 //... //initialize RequestDispatcher object; set forward to home page by default RequestDispatcher rd = request.getRequestDispatcher("home.jsp"); //Prepare connection and statement rs = stmt.executeQuery("select password from USER where userName = '" + userName + "'"); if (rs.next()) { //Query only returns 1 record in the result set; only 1 password per userName which is also the primary key if (rs.getString("password").equals(password)) { //If valid password session.setAttribute("User", userName); //Saves username string in the session object } else { //Password does not match, i.e., invalid user password request.setAttribute("Error", "Invalid password."); rd = request.getRequestDispatcher("login.jsp"); } } //No record in the result set, i.e., invalid username else { request.setAttribute("Error", "Invalid user name."); rd = request.getRequestDispatcher("login.jsp"); } } //As a controller, loginAction.jsp finally either forwards to "login.jsp" or "home.jsp" rd.forward(request, response); //... |
Listing 2 //... session.removeAttribute("User"); session.invalidate(); //... |
Listing 3 //... String userName = (String) session.getAttribute("User"); if (null == userName) { request.setAttribute("Error", "Session has ended. Please login."); RequestDispatcher rd = request.getRequestDispatcher("login.jsp"); rd.forward(request, response); } //... //Allow the rest of the dynamic content in this JSP to be served to the browser //... |
//... response.setHeader("Cache-Control","no-cache"); //Forces caches to obtain a new copy of the page from the origin server response.setHeader("Cache-Control","no-store"); //Directs caches not to store the page under any circumstance response.setDateHeader("Expires", 0); //Causes the proxy cache to see the page as "stale" response.setHeader("Pragma","no-cache"); //HTTP 1.0 backward compatibility String userName = (String) session.getAttribute("User"); if (null == userName) { request.setAttribute("Error", "Session has ended. Please login."); RequestDispatcher rd = request.getRequestDispatcher("login.jsp"); rd.forward(request, response); } //... |
//... RequestDispatcher rd = request.getRequestDispatcher("home.jsp"); //Forward to homepage by default //... if (rs.getString("password").equals(password)) { //If valid password long lastLogonDB = rs.getLong("lastLogon"); if (lastLogonForm > lastLogonDB) { session.setAttribute("User", userName); //Saves username string in the session object stmt.executeUpdate("update USER set lastLogon= " + lastLogonForm + " where userName = '" + userName + "'"); } else { request.setAttribute("Error", "Session has ended. Please login."); rd = request.getRequestDispatcher("login.jsp"); } } else { //Password does not match, i.e., invalid user password request.setAttribute("Error", "Invalid password."); rd = request.getRequestDispatcher("login.jsp"); } //... rd.forward(request, response); //... |
public abstract class BaseAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setHeader("Cache-Control","no-cache"); //Forces caches to obtain a new copy of the page from the origin server response.setHeader("Cache-Control","no-store"); //Directs caches not to store the page under any circumstance response.setDateHeader("Expires", 0); //Causes the proxy cache to see the page as "stale" response.setHeader("Pragma","no-cache"); //HTTP 1.0 backward compatibility if (!this.userIsLoggedIn(request)) { ActionErrors errors = new ActionErrors(); errors.add("error", new ActionError("logon.sessionEnded")); this.saveErrors(request, errors); return mapping.findForward("sessionEnded"); } return executeAction(mapping, form, request, response); } protected abstract ActionForward executeAction(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException; private boolean userIsLoggedIn(HttpServletRequest request) { if (request.getSession().getAttribute("User") == null) { return false; } return true; } } |
<action path="/secure1" type="com.kevinhle.logoutSampleStruts.Secure1Action" scope="request"> <forward name="success" path="/WEB-INF/jsps/secure1.jsp"/> <forward name="sessionEnded" path="/login.jsp"/> </action> |
public class Secure1Action extends BaseAction { public ActionForward executeAction(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { HttpSession session = request.getSession(); return (mapping.findForward("success")); } } |
Beanutils用了魔術(shù)般的反射技術(shù),實現(xiàn)了很多夸張有用的功能,都是C/C++時代不敢想的。無論誰的項目,始終一天都會用得上它。我算是后知后覺了,第一回看到它的時候居然錯過。
在這框架滿天飛的年代,不能事事都保證執(zhí)行g(shù)etter,setter函數(shù)了,有時候?qū)傩允且枰鶕?jù)名字動態(tài)的取得的,就像這樣:
BeanUtils.getProperty(myBean,"code");而BeanUtils更強的功能是直接訪問內(nèi)嵌對象的屬性,只要使用逗號分割。
BeanUtils.getProperty(orderBean, "address.city");
其他類庫的BeanUtils通常都很簡單,不能訪問內(nèi)嵌的對象,所以經(jīng)常要用Jakata的BeanUtils替換它們。
BeanUtils還支持List和Map類型的屬性。如下面的語法即可取得顧客列表中第一個顧客的名字
BeanUtils.getProperty(orderBean, "customers[1].name");
其中BeanUtils會使用ConvertUtils類把字符串轉(zhuǎn)為Bean屬性的真正類型,方便從HttpServletRequest等對象中提取bean,或者把bean輸出到頁面。
而PropertyUtils就會原色的保留Bean原來的類型。
還是通過反射,動態(tài)設(shè)定Bean按照哪個屬性來排序,而不再需要在bean的Compare接口進(jìn)行復(fù)雜的條件判斷。 List peoples = ...; // Person對象的列表 Collections.sort(peoples, new BeanComparator("age")); }}} 如果要支持多個屬性的復(fù)合排序,如"Order By lastName,firstName" ArrayList sortFields = new ArrayList();
sortFields.add(new BeanComparator("lastName"));
sortFields.add(new BeanComparator("firstName"));
ComparatorChain multiSort = new ComparatorChain(sortFields);
Collections.sort(rows,multiSort);
其中ComparatorChain屬于jakata commons-collections包。
如果age屬性不是普通類型,構(gòu)造函數(shù)需要再傳入一個comparator對象為age變量排序。
String a = request.getParameter("a"); bean.setA(a); String b = ....不妨改為
MyBean bean = ...; HashMap map = new HashMap(); Enumeration names = request.getParameterNames(); while (names.hasMoreElements()) { String name = (String) names.nextElement(); map.put(name, request.getParameterValues(name)); } BeanUtils.populate(bean, map);其中BeanUtils的populate方法或者getProperty,setProperty方法其實都會調(diào)用convert進(jìn)行轉(zhuǎn)換。
但Converter只支持一些基本的類型,甚至連java.util.Date類型也不支持。而且它比較笨的一個地方是當(dāng)遇到不認(rèn)識的類型時,居然會拋出異常來。
對于Date類型,我參考它的sqldate類型實現(xiàn)了一個Converter,而且添加了一個設(shè)置日期格式的函數(shù)。要把這個Converter注冊,需要如下語句:
ConvertUtilsBean convertUtils = new ConvertUtilsBean(); DateConverter dateConverter = new DateConverter(); convertUtils.register(dateConverter,Date.class); //因為要注冊converter,所以不能再使用BeanUtils的靜態(tài)方法了,必須創(chuàng)建BeanUtilsBean實例 BeanUtilsBean beanUtils = new BeanUtilsBean(convertUtils,new PropertyUtilsBean()); beanUtils.setProperty(bean, name, value); !4 其他功能 4.1 PropertyUtils,當(dāng)屬性為Collection,Map時的動態(tài)讀取: Collection: 提供index {{{ BeanUtils.getIndexedProperty(orderBean,"items",1);或者
BeanUtils.getIndexedProperty(orderBean,"items[1]");
Map: 提供Key Value
BeanUtils.getMappedProperty(orderBean, "items","111");//key-value goods_no=111
或者
BeanUtils.getMappedProperty(orderBean, "items(111)");4.2 PropertyUtils,獲取屬性的Class類型
public static Class getPropertyType(Object bean, String name)
4.3 ConstructorUtils,動態(tài)創(chuàng)建對象
public static Object invokeConstructor(Class klass, Object arg)
4.4 DynaClass動態(tài)類
Struts的Token(令牌)機制能夠很好的解決表單重復(fù)提交的問題,基本原理是:服務(wù)器端在處理到達(dá)的請求之前,會將請求中包含的令牌值與保存在當(dāng)前用戶會話中的令牌值進(jìn)行比較,看是否匹配。在處理完該請求后,且在答復(fù)發(fā)送給客戶端之前,將會產(chǎn)生一個新的令牌,該令牌除傳給客戶端以外,也會將用戶會話中保存的舊的令牌進(jìn)行替換。這樣如果用戶回退到剛才的提交頁面并再次提交的話,客戶端傳過來的令牌就和服務(wù)器端的令牌不一致,從而有效地防止了重復(fù)提交的發(fā)生。
這時其實也就是兩點,第一:你需要在請求中有這個令牌值,請求中的令牌值如何保存,其實就和我們平時在頁面中保存一些信息是一樣的,通過隱藏字段來保存,保存的形式如: 〈input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="6aa35341f25184fd996c4c918255c3ae"〉,這個value是TokenProcessor類中的generateToken()獲得的,是根據(jù)當(dāng)前用戶的session id和當(dāng)前時間的long值來計算的。第二:在客戶端提交后,我們要根據(jù)判斷在請求中包含的值是否和服務(wù)器的令牌一致,因為服務(wù)器每次提交都會生成新的Token,所以,如果是重復(fù)提交,客戶端的Token值和服務(wù)器端的Token值就會不一致。下面就以在數(shù)據(jù)庫中插入一條數(shù)據(jù)來說明如何防止重復(fù)提交。
在Action中的add方法中,我們需要將Token值明確的要求保存在頁面中,只需增加一條語句:saveToken(request);,如下所示:
public ActionForward add(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
//前面的處理省略
saveToken(request);
return mapping.findForward("add");
}在Action的insert方法中,我們根據(jù)表單中的Token值與服務(wù)器端的Token值比較,如下所示:
public ActionForward insert(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
if (isTokenValid(request, true)) {
// 表單不是重復(fù)提交
//這里是保存數(shù)據(jù)的代碼
} else {
//表單重復(fù)提交
saveToken(request);
//其它的處理代碼
}
}
其實使用起來很簡單,舉個最簡單、最需要使用這個的例子:
一般控制重復(fù)提交主要是用在對數(shù)據(jù)庫操作的控制上,比如插入、更新、刪除等,由于更新、刪除一般都是通過id來操作(例如:updateXXXById, removeXXXById),所以這類操作控制的意義不是很大(不排除個別現(xiàn)象),重復(fù)提交的控制也就主要是在插入時的控制了。
先說一下,我們目前所做項目的情況:
目前的項目是用Struts+Spring+I(xiàn)batis,頁面用jstl,Struts復(fù)雜View層,Spring在Service層提供事務(wù)控制,Ibatis是用來代替JDBC,所有頁面的訪問都不是直接訪問jsp,而是訪問Structs的Action,再由Action來Forward到一個Jsp,所有針對數(shù)據(jù)庫的操作,比如取數(shù)據(jù)或修改數(shù)據(jù),都是在Action里面完成,所有的Action一般都繼承BaseDispatchAction,這個是自己建立的類,目的是為所有的Action做一些統(tǒng)一的控制,在Struts層,對于一個功能,我們一般分為兩個Action,一個Action里的功能是不需要調(diào)用Struts的驗證功能的(常見的方法名稱有add,edit,remove,view,list),另一個是需要調(diào)用Struts的驗證功能的(常見的方法名稱有insert,update)。
就拿論壇發(fā)貼來說吧,論壇發(fā)貼首先需要跳轉(zhuǎn)到一個頁面,你可以填寫帖子的主題和內(nèi)容,填寫完后,單擊“提交”,貼子就發(fā)表了,所以這里經(jīng)過兩個步驟:
1、轉(zhuǎn)到一個新增的頁面,在Action里我們一般稱為add,例如:
public ActionForward add(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
//這一句是輸出調(diào)試信息,表示代碼執(zhí)行到這一段了
log.debug(":: action - subject add");
//your code here
//這里保存Token值
saveToken(request);
//跳轉(zhuǎn)到add頁面,在Structs-config.xml里面定義,例如,跳轉(zhuǎn)到subjectAdd.jsp
return mapping.findForward("add");
}
2、在填寫標(biāo)題和內(nèi)容后,選擇 提交 ,會提交到insert方法,在insert方法里判斷,是否重復(fù)提交了。
public ActionForward insert(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response){
if (isTokenValid(request, true)) {
// 表單不是重復(fù)提交
//這里是保存數(shù)據(jù)的代碼
} else {
//表單重復(fù)提交
saveToken(request);
//其它的處理代碼
}
}
下面更詳細(xì)一點(注意,下面所有的代碼使用全角括號):
1、你想發(fā)貼時,點擊“我要發(fā)貼”鏈接的代碼可以里這樣的:
〈html:link action="subject.do?method=add"〉我要發(fā)貼〈/html:link〉
subject.do 和 method 這些在struct-config.xml如何定義我就不說了,點擊鏈接后,會執(zhí)行subject.do的add方法,代碼如上面說的,跳轉(zhuǎn)到subjectAdd.jsp頁面。頁面的代碼大概如下:
〈html:form action="subjectForm.do?method=insert"〉
〈html:text property="title" /〉
〈html:textarea property="content" /〉
〈html:submit property="發(fā)表" /〉
〈html:reset property="重填" /〉
〈html:form〉
如果你在add方法里加了“saveToken(request);”這一句,那在subjectAdd.jsp生成的頁面上,會多一個隱藏字段,類似于這樣〈input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="6aa35341f25184fd996c4c918255c3ae"〉,
2、點擊發(fā)表后,表單提交到subjectForm.do里的insert方法后,你在insert方法里要將表單的數(shù)據(jù)插入到數(shù)據(jù)庫中,如果沒有進(jìn)行重復(fù)提交的控制,那么每點擊一次瀏覽器的刷新按鈕,都會在數(shù)據(jù)庫中插入一條相同的記錄,增加下面的代碼,你就可以控制用戶的重復(fù)提交了。
if (isTokenValid(request, true)) {
// 表單不是重復(fù)提交
//這里是保存數(shù)據(jù)的代碼
} else {
//表單重復(fù)提交
saveToken(request);
//其它的處理代碼
}
注意,你必須在add方法里使用了saveToken(request),你才能在insert里判斷,否則,你每次保存操作都是重復(fù)提交。
記住一點,Struts在你每次訪問Action的時候,都會產(chǎn)生一個令牌,保存在你的Session里面,如果你在Action里的函數(shù)里面,使用了saveToken(request);,那么這個令牌也會保存在這個Action所Forward到的jsp所生成的靜態(tài)頁面里。
如果你在你Action的方法里使用了isTokenValid,那么Struts會將你從你的request里面去獲取這個令牌值,然后和Session里的令牌值做比較,如果兩者相等,就不是重復(fù)提交,如果不相等,就是重復(fù)提交了。
由于我們項目的所有Action都是繼承自BaseDispatchAction這個類,所以我們基本上都是在這個類里面做了表單重復(fù)提交的控制,默認(rèn)是控制add方法和insert方法,如果需要控制其它的方法,就自己手動寫上面這些代碼,否則是不需要手寫的,控制的代碼如下:
public abstract class BaseDispatchAction extends BaseAction {
protected ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
String parameter = mapping.getParameter();
String name = request.getParameter(parameter);
if (null == name) { //如果沒有指定 method ,則默認(rèn)為 list
name = "list";
}
if ("add".equals(name)) {
if ("add".equals(name)) {
saveToken(request);
}
} else if ("insert".equals(name)) {
if (!isTokenValid(request, true)) {
resetToken(request);
saveError(request, new ActionMessage("error.repeatSubmit"));
log.error("重復(fù)提交!");
return mapping.findForward("error");
}
}
return dispatchMethod2(mapping, form, request, response, name);
}
}
SELECT COUNT(*) AS Expr1 FROM History
DELETE FROM History WHERE (Id > 0)
truncate table youtable;
為什么要用TRUNCATE TABLE 語句代替DELETE語句?當(dāng)你使用TRUNCATE TABLE語句時,記錄的刪除是不作記錄的。也就是說,這意味著TRUNCATE TABLE 要比DELETE快得多。
我今年39歲了,25歲研究生畢業(yè),工作14年,回頭看看,應(yīng)該說走了不少的彎路,有一些經(jīng)驗和教訓(xùn)。現(xiàn)在開一個小公司,賺的錢剛夠養(yǎng)家糊口的。看看這些剛畢業(yè)的學(xué)生,對前景也很迷茫,想拋磚引玉,談?wù)勛约旱目捶ǎ窒抻诶砉た频膶W(xué)生,我對文科的不懂,身邊的朋友也沒有這一類型的。滾動公告欄的實現(xiàn)
用到如下html標(biāo)簽:
《MARQUEE id=mar onmouseout=this.start(); direction=up height=150 name="mar"
onmouseover="this.stop();" scrollAmount="1" scrollDelay="0"
style="LINE-HEIGHT: 100%; PADDING-LEFT: 0px; PADDING-RIGHT:0px"width="100%">
1凈化社會環(huán)境
2也是凈化社會平步青云
3凈化社會環(huán)境
4也是凈化社會平步青云
5凈化社會環(huán)境
6也是凈化社會平步青云
7凈化社會環(huán)境
8也是凈化社會平步青云
其中marquee中height中的屬性可以更改每次顯示的行數(shù),……