????<data-sources>
????????<data-source?key="rki"?type="org.apache.commons.dbcp.BasicDataSource">? //type代表類，rki表示當(dāng)有多個(gè)數(shù)據(jù)源時(shí)相
//當(dāng)于一個(gè)索引，id值
????????????<set-property?property="driverClassName"?value="org.gjt.mm.mysql.Driver"?/>//連接mysql所需的類庫
????????????<set-property?property="url"?value="jdbc:mysql://172.20.0.40:3306/test?useUnicode=true&amp;characterEncoding=GBK"?/>
????????????<set-property?property="username"?value="root"?/>
????????????<set-property?property="password"?value="你的密碼"?/>
????????????<set-property?property="maxActive"?value="10"?/>
????????????<set-property?property="maxWait"?value="500"?/>
????????????<set-property?property="defaultAutoCommit"?value="false"?/>
????????????<set-property?property="defaultReadOnly"?value="false"?/>
????????</data-source>
????</data-sources>

datasource?=?getDataSource(request,?"rki");
????????????conn?=?datasource.getConnection();
????????????Statement?state?=?conn.createStatement();
????????????System.out.println("hello");
????????????String?sql?=?"select?*?from?notice?where?title='test'";
????????????ResultSet?rs?=?state.executeQuery(sql);
????????????while?(rs.next())?{
????????????????request.getSession().setAttribute("cont",
????????????????????????rs.getString("content"));
????????????????System.out.println("database?connect?true");
????????????}
????????????rs.close();

????public?ActionErrors?validate(ActionMapping?mapping,
????????????HttpServletRequest?request)?{
????????ActionErrors?errors?=?new?ActionErrors();
????????if?(this.content.equals(""))?{
????????????errors.add("content",?new?ActionError("error.user"));
????????}
????????return?errors;
????}

這就是在前面的簡(jiǎn)單應(yīng)用中，在view中，通過<bean:write name="myform" property="name">調(diào)用Actionform時(shí)出的問題，這個(gè)問題的直接原因很簡(jiǎn)單就是：找不到"myform"這個(gè)Bean，用網(wǎng)上的話說就是“在Action里一般會(huì)request.setAttribute()一些對(duì)象，然后在轉(zhuǎn)向的jsp文件里（用tag或request.getAttribute()方法）得到這些對(duì)象并顯示出來。這個(gè)異常是說jsp要得到一個(gè)對(duì)象，但前面的Action里并沒有將對(duì)象設(shè)置到request（也可以是session、servletContext）里。可能是名字錯(cuò)了，請(qǐng)檢查jsp里的tag的一般是name屬性，或getAttribute()方法的參數(shù)值；或者是Action邏輯有問題沒有執(zhí)行setAttribute()方法就先轉(zhuǎn)向了。
還有另外一個(gè)可能，純粹是jsp文件的問題，例如<logic:iterate>會(huì)指定一個(gè)id值，然后在循環(huán)里<bean:write>使用這個(gè)值作為name的值，如果這兩個(gè)值不同，也會(huì)出現(xiàn)此異常。（都是一個(gè)道理，request里沒有對(duì)應(yīng)的對(duì)象。）”。
??????我對(duì)Actionform的機(jī)制不理解，心中的疑問：
??????1）如果ActionForm是Struts自動(dòng)封裝到Request中，那么我可以直接在view.jsp中，能過<bean:write>調(diào)用這個(gè)ActionForm，如果假設(shè)這種情況成立時(shí)，那么Beanwrite中的bean名應(yīng)該是ActionForm的類名，還是在Struts-config.xml里給ActionForm定義的類名？
????? 2）如果沒有封裝的話，那么是不是需要在Action中把Actionform通過request.setAttribute("","")放到request中
還是要放到Session中，
????? 我測(cè)試時(shí)候出的問題
?????? 有一次就是在1）的情況下測(cè)試成功的，但是以后再怎么試都不行，那次是引用的Struts-config.xml里給ActionForm定義的類名。非常奇怪，
????????還有就是2）的情況，測(cè)試中如果Action和Frombean在一個(gè)包下面，那么通過request.setAttribute("","")，就可以獲取到Bean，如果不是的話，有時(shí)候行，有時(shí)候不行，
??????? 如果通過request.getSession.setAttribute()設(shè)置ActionForm的話，每次都可以，他們的Scope肯定在一個(gè)Request中，那么為什么Session就可以，而Request不行。(結(jié)論：因?yàn)槭窃贏ctionfoward中設(shè)置了“redirect='true'，這樣的話一跳轉(zhuǎn)時(shí)，Request中的內(nèi)容都會(huì)被重置，所以不行，把這一句去掉就可以了”)

源代碼
Strust-config.xml

<form-bean?name="upNewsForm"?type="com.rkind.struts.form.UpNewsForm"?/>

????????<action?attribute="upNewsForm"?input="/upNews.jsp"?name="upNewsForm"?path="/upNews"?scope="request"?type="com.rkind.struts.action.UpNewsAction">
????????????<forward?name="suc"?path="/show.jsp"?redirect="true"?/>
????????</action>

<html:form?action="/upNews">
????????????content?:?<html:text?property="content"/><html:errors?property="content"/><br/>
????????????<html:submit/><html:cancel/>
????????</html:form>

<bean:write?name="upNewsForm"?property="content"/>

UpNewsForm?upNewsForm?=?(UpNewsForm)?form;
????????//?TODO?Auto-generated?method?stub
????????String?te=upNewsForm.getContent();
????????try{
????????if(te.equals("")){
????????????return?new?ActionForward(mapping.getInput());????????
????????}
????????return?(mapping.findForward("suc"));
????????}catch(Exception?e){
????????????throw?new?RuntimeException(e.getMessage());

1、插入和包含
???1）???js,一般都放在head之間、注釋的作用是當(dāng)客戶端瀏覽器版本過低時(shí)，不能識(shí)別而發(fā)生錯(cuò)誤
<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>

一、術(shù)語session

　　在我的經(jīng)驗(yàn)里，session這個(gè)詞被濫用的程度大概僅次于transaction，更加有趣的是transaction與session在某些語境下的含義是相同的。

　　session，中文經(jīng)常翻譯為會(huì)話，其本來的含義是指有始有終的一系列動(dòng)作/消息，比如打電話時(shí)從拿起電話撥號(hào)到掛斷電話這中間的一系列過程可以稱之為一個(gè)session。有時(shí)候我們可以看到這樣的話“在一個(gè)瀏覽器會(huì)話期間，...”，這里的會(huì)話一詞用的就是其本義，是指從一個(gè)瀏覽器窗口打開到關(guān)閉這個(gè)期間①。最混亂的是“用戶（客戶端）在一次會(huì)話期間”這樣一句話，它可能指用戶的一系列動(dòng)作（一般情況下是同某個(gè)具體目的相關(guān)的一系列動(dòng)作，比如從登錄到選購商品到結(jié)賬登出這樣一個(gè)網(wǎng)上購物的過程，有時(shí)候也被稱為一個(gè)transaction），然而有時(shí)候也可能僅僅是指一次連接，也有可能是指含義①，其中的差別只能靠上下文來推斷②。

　　然而當(dāng)session一詞與網(wǎng)絡(luò)協(xié)議相關(guān)聯(lián)時(shí)，它又往往隱含了“面向連接”和/或“保持狀態(tài)”這樣兩個(gè)含義，“面向連接”指的是在通信雙方在通信之前要先建立一個(gè)通信的渠道，比如打電話，直到對(duì)方接了電話通信才能開始，與此相對(duì)的是寫信，在你把信發(fā)出去的時(shí)候你并不能確認(rèn)對(duì)方的地址是否正確，通信渠道不一定能建立，但對(duì)發(fā)信人來說，通信已經(jīng)開始了。“保持狀態(tài)”則是指通信的一方能夠把一系列的消息關(guān)聯(lián)起來，使得消息之間可以互相依賴，比如一個(gè)服務(wù)員能夠認(rèn)出再次光臨的老顧客并且記得上次這個(gè)顧客還欠店里一塊錢。這一類的例子有“一個(gè)TCP session”或者“一個(gè)POP3 session”③。

　　而到了web服務(wù)器蓬勃發(fā)展的時(shí)代，session在web開發(fā)語境下的語義又有了新的擴(kuò)展，它的含義是指一類用來在客戶端與服務(wù)器之間保持狀態(tài)的解決方案④。有時(shí)候session也用來指這種解決方案的存儲(chǔ)結(jié)構(gòu)，如“把xxx保存在session里”⑤。由于各種用于web開發(fā)的語言在一定程度上都提供了對(duì)這種解決方案的支持，所以在某種特定語言的語境下，session也被用來指代該語言的解決方案，比如經(jīng)常把Java里提供的javax.servlet.http.HttpSession簡(jiǎn)稱為session⑥。

　　鑒于這種混亂已不可改變，本文中session一詞的運(yùn)用也會(huì)根據(jù)上下文有不同的含義，請(qǐng)大家注意分辨。

　　在本文中，使用中文“瀏覽器會(huì)話期間”來表達(dá)含義①，使用“session機(jī)制”來表達(dá)含義④，使用“session”表達(dá)含義⑤，使用具體的“HttpSession”來表達(dá)含義⑥

　　二、HTTP協(xié)議與狀態(tài)保持

　　HTTP協(xié)議本身是無狀態(tài)的，這與HTTP協(xié)議本來的目的是相符的，客戶端只需要簡(jiǎn)單的向服務(wù)器請(qǐng)求下載某些文件，無論是客戶端還是服務(wù)器都沒有必要紀(jì)錄彼此過去的行為，每一次請(qǐng)求之間都是獨(dú)立的，好比一個(gè)顧客和一個(gè)自動(dòng)售貨機(jī)或者一個(gè)普通的（非會(huì)員制）大賣場(chǎng)之間的關(guān)系一樣。

　　然而聰明（或者貪心？）的人們很快發(fā)現(xiàn)如果能夠提供一些按需生成的動(dòng)態(tài)信息會(huì)使web變得更加有用，就像給有線電視加上點(diǎn)播功能一樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為，另一方面在服務(wù)器端則出現(xiàn)了CGI規(guī)范以響應(yīng)客戶端的動(dòng)態(tài)請(qǐng)求，作為傳輸載體的HTTP協(xié)議也添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作出的努力。至于后來出現(xiàn)的session機(jī)制則是又一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案。

　　讓我們用幾個(gè)例子來描述一下cookie和session機(jī)制之間的區(qū)別與聯(lián)系。筆者曾經(jīng)常去的一家咖啡店有喝5杯咖啡免費(fèi)贈(zèng)一杯咖啡的優(yōu)惠，然而一次性消費(fèi)5杯咖啡的機(jī)會(huì)微乎其微，這時(shí)就需要某種方式來紀(jì)錄某位顧客的消費(fèi)數(shù)量。想象一下其實(shí)也無外乎下面的幾種方案：

　　1、該店的店員很厲害，能記住每位顧客的消費(fèi)數(shù)量，只要顧客一走進(jìn)咖啡店，店員就知道該怎么對(duì)待了。這種做法就是協(xié)議本身支持狀態(tài)。

　　2、發(fā)給顧客一張卡片，上面記錄著消費(fèi)的數(shù)量，一般還有個(gè)有效期限。每次消費(fèi)時(shí)，如果顧客出示這張卡片，則此次消費(fèi)就會(huì)與以前或以后的消費(fèi)相聯(lián)系起來。這種做法就是在客戶端保持狀態(tài)。

　　3、發(fā)給顧客一張會(huì)員卡，除了卡號(hào)之外什么信息也不紀(jì)錄，每次消費(fèi)時(shí)，如果顧客出示該卡片，則店員在店里的紀(jì)錄本上找到這個(gè)卡號(hào)對(duì)應(yīng)的紀(jì)錄添加一些消費(fèi)信息。這種做法就是在服務(wù)器端保持狀態(tài)。

　　由于HTTP協(xié)議是無狀態(tài)的，而出于種種考慮也不希望使之成為有狀態(tài)的，因此，后面兩種方案就成為現(xiàn)實(shí)的選擇。具體來說cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。同時(shí)我們也看到，由于采用服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個(gè)標(biāo)識(shí)，所以session機(jī)制可能需要借助于cookie機(jī)制來達(dá)到保存標(biāo)識(shí)的目的，但實(shí)際上它還有其他選擇。

　　三、理解cookie機(jī)制

　　cookie機(jī)制的基本原理就如上面的例子一樣簡(jiǎn)單，但是還有幾個(gè)問題需要解決：“會(huì)員卡”如何分發(fā)；“會(huì)員卡”的內(nèi)容；以及客戶如何使用“會(huì)員卡”。

　　正統(tǒng)的cookie分發(fā)是通過擴(kuò)展HTTP協(xié)議來實(shí)現(xiàn)的，服務(wù)器通過在HTTP的響應(yīng)頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應(yīng)的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。

　　而cookie的使用是由瀏覽器按照一定的原則在后臺(tái)自動(dòng)發(fā)送給服務(wù)器的。瀏覽器檢查所有存儲(chǔ)的cookie，如果某個(gè)cookie所聲明的作用范圍大于等于將要請(qǐng)求的資源所在的位置，則把該cookie附在請(qǐng)求資源的HTTP請(qǐng)求頭上發(fā)送給服務(wù)器。意思是麥當(dāng)勞的會(huì)員卡只能在麥當(dāng)勞的店里出示，如果某家分店還發(fā)行了自己的會(huì)員卡，那么進(jìn)這家店的時(shí)候除了要出示麥當(dāng)勞的會(huì)員卡，還要出示這家店的會(huì)員卡。

　　cookie的內(nèi)容主要包括：名字，值，過期時(shí)間，路徑和域。

　　其中域可以指定某一個(gè)域比如.google.com，相當(dāng)于總店招牌，比如寶潔公司，也可以指定一個(gè)域下的具體某臺(tái)機(jī)器比如www.google.com或者froogle.google.com，可以用飄柔來做比。

　　路徑就是跟在域名后面的URL路徑，比如/或者/foo等等，可以用某飄柔專柜做比。

　　路徑與域合在一起就構(gòu)成了cookie的作用范圍。

　　如果不設(shè)置過期時(shí)間，則表示這個(gè)cookie的生命期為瀏覽器會(huì)話期間，只要關(guān)閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽器會(huì)話期的cookie被稱為會(huì)話cookie。會(huì)話cookie一般不存儲(chǔ)在硬盤上而是保存在內(nèi)存里，當(dāng)然這種行為并不是規(guī)范規(guī)定的。如果設(shè)置了過期時(shí)間，瀏覽器就會(huì)把cookie保存到硬盤上，關(guān)閉后再次打開瀏覽器，這些cookie仍然有效直到超過設(shè)定的過期時(shí)間。

　　存儲(chǔ)在硬盤上的cookie可以在不同的瀏覽器進(jìn)程間共享，比如兩個(gè)IE窗口。而對(duì)于保存在內(nèi)存里的cookie，不同的瀏覽器有不同的處理方式。對(duì)于IE，在一個(gè)打開的窗口上按Ctrl-N（或者從文件菜單）打開的窗口可以與原窗口共享，而使用其他方式新開的IE進(jìn)程則不能共享已經(jīng)打開的窗口的內(nèi)存cookie；對(duì)于Mozilla Firefox0.8，所有的進(jìn)程和標(biāo)簽頁都可以共享同樣的cookie。一般來說是用javascript的window.open打開的窗口會(huì)與原窗口共享內(nèi)存cookie。瀏覽器對(duì)于會(huì)話cookie的這種只認(rèn)cookie不認(rèn)人的處理方式經(jīng)常給采用session機(jī)制的web應(yīng)用程序開發(fā)者造成很大的困擾。

　　下面就是一個(gè)goolge設(shè)置cookie的響應(yīng)頭的例子

HTTP/1.1 302 Found
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

　　這是使用HTTPLook這個(gè)HTTP Sniffer軟件來俘獲的HTTP通訊紀(jì)錄的一部分

　　瀏覽器在再次訪問goolge的資源時(shí)自動(dòng)向外發(fā)送cookie

　　使用Firefox可以很容易的觀察現(xiàn)有的cookie的值

　　使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

　　IE也可以設(shè)置在接受cookie前詢問

　　這是一個(gè)詢問接受cookie的對(duì)話框。

　　四、理解session機(jī)制

　session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來保存信息。

　　當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí) - 稱為session id，如果已包含一個(gè)session id則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照session id把這個(gè)session檢索出來使用（如果檢索不到，可能會(huì)新建一個(gè)），如果客戶端請(qǐng)求不包含session id，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè)session id將被在本次響應(yīng)中返回給客戶端保存。

　　保存這個(gè)session id的方式可以采用cookie，這樣在交互過程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)揮給服務(wù)器。一般這個(gè)cookie的名字都是類似于SEEESIONID，而。比如weblogic對(duì)于web應(yīng)用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

　　由于cookie可以被人為的禁止，必須有其他機(jī)制以便在cookie被禁止時(shí)仍然能夠把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
這兩種方式對(duì)于用戶來說是沒有區(qū)別的，只是服務(wù)器在解析的時(shí)候處理的方式不同，采用第一種方式也有利于把session id的信息和正常程序參數(shù)區(qū)分開來。

　　為了在整個(gè)交互過程中始終保持狀態(tài)，就必須在每個(gè)客戶端可能請(qǐng)求的路徑后面都包含這個(gè)session id。

　　另一種技術(shù)叫做表單隱藏字段。就是服務(wù)器會(huì)自動(dòng)修改表單，添加一個(gè)隱藏字段，以便在表單提交時(shí)能夠把session id傳遞回服務(wù)器。比如下面的表單

　　在被傳遞給客戶端之前將被改寫成

　　這種技術(shù)現(xiàn)在已較少應(yīng)用，筆者接觸過的很古老的iPlanet6(SunONE應(yīng)用服務(wù)器的前身)就使用了這種技術(shù)。實(shí)際上這種技術(shù)可以簡(jiǎn)單的用對(duì)action應(yīng)用URL重寫來代替。

　　在談?wù)搒ession機(jī)制的時(shí)候，常常聽到這樣一種誤解“只要關(guān)閉瀏覽器，session就消失了”。其實(shí)可以想象一下會(huì)員卡的例子，除非顧客主動(dòng)對(duì)店家提出銷卡，否則店家絕對(duì)不會(huì)輕易刪除顧客的資料。對(duì)session來說也是一樣的，除非程序通知服務(wù)器刪除一個(gè)session，否則服務(wù)器會(huì)一直保留，程序一般都是在用戶做log off的時(shí)候發(fā)個(gè)指令去刪除session。然而瀏覽器從來不會(huì)主動(dòng)在關(guān)閉之前通知服務(wù)器它將要關(guān)閉，因此服務(wù)器根本不會(huì)有機(jī)會(huì)知道瀏覽器已經(jīng)關(guān)閉，之所以會(huì)有這種錯(cuò)覺，是大部分session機(jī)制都使用會(huì)話cookie來保存session id，而關(guān)閉瀏覽器后這個(gè)session id就消失了，再次連接服務(wù)器時(shí)也就無法找到原來的session。如果服務(wù)器設(shè)置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發(fā)出的HTTP請(qǐng)求頭，把原來的session id發(fā)送給服務(wù)器，則再次打開瀏覽器仍然能夠找到原來的session。

　　恰恰是由于關(guān)閉瀏覽器不會(huì)導(dǎo)致session被刪除，迫使服務(wù)器為seesion設(shè)置了一個(gè)失效時(shí)間，當(dāng)距離客戶端上一次使用session的時(shí)間超過這個(gè)失效時(shí)間時(shí)，服務(wù)器就可以認(rèn)為客戶端已經(jīng)停止了活動(dòng)，才會(huì)把session刪除以節(jié)省存儲(chǔ)空間。

　　五、理解javax.servlet.http.HttpSession

　　HttpSession是Java平臺(tái)對(duì)session機(jī)制的實(shí)現(xiàn)規(guī)范，因?yàn)樗鼉H僅是個(gè)接口，具體到每個(gè)web應(yīng)用服務(wù)器的提供商，除了對(duì)規(guī)范支持之外，仍然會(huì)有一些規(guī)范里沒有規(guī)定的細(xì)微差異。這里我們以BEA的Weblogic Server8.1作為例子來演示。

　　首先，Weblogic Server提供了一系列的參數(shù)來控制它的HttpSession的實(shí)現(xiàn)，包括使用cookie的開關(guān)選項(xiàng)，使用URL重寫的開關(guān)選項(xiàng)，session持久化的設(shè)置，session失效時(shí)間的設(shè)置，以及針對(duì)cookie的各種設(shè)置，比如設(shè)置cookie的名字、路徑、域，cookie的生存時(shí)間等。

　　一般情況下，session都是存儲(chǔ)在內(nèi)存里，當(dāng)服務(wù)器進(jìn)程被停止或者重啟的時(shí)候，內(nèi)存里的session也會(huì)被清空，如果設(shè)置了session的持久化特性，服務(wù)器就會(huì)把session保存到硬盤上，當(dāng)服務(wù)器進(jìn)程重新啟動(dòng)或這些信息將能夠被再次使用，Weblogic Server支持的持久性方式包括文件、數(shù)據(jù)庫、客戶端cookie保存和復(fù)制。

　　復(fù)制嚴(yán)格說來不算持久化保存，因?yàn)閟ession實(shí)際上還是保存在內(nèi)存里，不過同樣的信息被復(fù)制到各個(gè)cluster內(nèi)的服務(wù)器進(jìn)程中，這樣即使某個(gè)服務(wù)器進(jìn)程停止工作也仍然可以從其他進(jìn)程中取得session。

　　cookie生存時(shí)間的設(shè)置則會(huì)影響瀏覽器生成的cookie是否是一個(gè)會(huì)話cookie。默認(rèn)是使用會(huì)話cookie。有興趣的可以用它來試驗(yàn)我們?cè)诘谒墓?jié)里提到的那個(gè)誤解。

　　cookie的路徑對(duì)于web應(yīng)用程序來說是一個(gè)非常重要的選項(xiàng)，Weblogic Server對(duì)這個(gè)選項(xiàng)的默認(rèn)處理方式使得它與其他服務(wù)器有明顯的區(qū)別。后面我們會(huì)專題討論。

　　關(guān)于session的設(shè)置參考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

　　六、HttpSession常見問題

　　（在本小節(jié)中session的含義為⑤和⑥的混合）

　　1、session在何時(shí)被創(chuàng)建

　　一個(gè)常見的誤解是以為session在有客戶端訪問時(shí)就被創(chuàng)建，然而事實(shí)是直到某server端程序調(diào)用HttpServletRequest.getSession(true)這樣的語句時(shí)才被創(chuàng)建，注意如果JSP沒有顯示的使用 <%@page session="false"%>關(guān)閉session，則JSP文件在編譯成Servlet時(shí)將會(huì)自動(dòng)加上這樣一條語句HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的session對(duì)象的來歷。

　　由于session會(huì)消耗內(nèi)存資源，因此，如果不打算使用session，應(yīng)該在所有的JSP中關(guān)閉它。

　　2、session何時(shí)被刪除

　　綜合前面的討論，session在下列情況下被刪除a.程序調(diào)用HttpSession.invalidate();或b.距離上一次收到客戶端發(fā)送的session id時(shí)間間隔超過了session的超時(shí)設(shè)置;或c.服務(wù)器進(jìn)程被停止（非持久session）

　　3、如何做到在瀏覽器關(guān)閉時(shí)刪除session

　　嚴(yán)格的講，做不到這一點(diǎn)。可以做一點(diǎn)努力的辦法是在所有的客戶端頁面里使用javascript代碼window.oncolose來監(jiān)視瀏覽器的關(guān)閉動(dòng)作，然后向服務(wù)器發(fā)送一個(gè)請(qǐng)求來刪除session。但是對(duì)于瀏覽器崩潰或者強(qiáng)行殺死進(jìn)程這些非常規(guī)手段仍然無能為力。

　　4、有個(gè)HttpSessionListener是怎么回事

　　你可以創(chuàng)建這樣的listener去監(jiān)控session的創(chuàng)建和銷毀事件，使得在發(fā)生這樣的事件時(shí)你可以做一些相應(yīng)的工作。注意是session的創(chuàng)建和銷毀動(dòng)作觸發(fā)listener，而不是相反。類似的與HttpSession有關(guān)的listener還有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。

5、存放在session中的對(duì)象必須是可序列化的嗎

　　不是必需的。要求對(duì)象可序列化只是為了session能夠在集群中被復(fù)制或者能夠持久保存或者在必要時(shí)server能夠暫時(shí)把session交換出內(nèi)存。在Weblogic Server的session中放置一個(gè)不可序列化的對(duì)象在控制臺(tái)上會(huì)收到一個(gè)警告。我所用過的某個(gè)iPlanet版本如果session中有不可序列化的對(duì)象，在session銷毀時(shí)會(huì)有一個(gè)Exception，很奇怪。

　　6、如何才能正確的應(yīng)付客戶端禁止cookie的可能性

　　對(duì)所有的URL使用URL重寫，包括超鏈接，form的action，和重定向的URL，具體做法參見[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

　　7、開兩個(gè)瀏覽器窗口訪問應(yīng)用程序會(huì)使用同一個(gè)session還是不同的session

　　參見第三小節(jié)對(duì)cookie的討論，對(duì)session來說是只認(rèn)id不認(rèn)人，因此不同的瀏覽器，不同的窗口打開方式以及不同的cookie存儲(chǔ)方式都會(huì)對(duì)這個(gè)問題的答案有影響。

　　8、如何防止用戶打開兩個(gè)瀏覽器窗口操作導(dǎo)致的session混亂

　　這個(gè)問題與防止表單多次提交是類似的，可以通過設(shè)置客戶端的令牌來解決。就是在服務(wù)器每次生成一個(gè)不同的id返回給客戶端，同時(shí)保存在session里，客戶端提交表單時(shí)必須把這個(gè)id也返回服務(wù)器，程序首先比較返回的id與保存在session里的值是否一致，如果不一致則說明本次操作已經(jīng)被提交過了。可以參看《J2EE核心模式》關(guān)于表示層模式的部分。需要注意的是對(duì)于使用javascript window.open打開的窗口，一般不設(shè)置這個(gè)id，或者使用單獨(dú)的id，以防主窗口無法操作，建議不要再window.open打開的窗口里做修改操作，這樣就可以不用設(shè)置。

　　9、為什么在Weblogic Server中改變session的值后要重新調(diào)用一次session.setValue
做這個(gè)動(dòng)作主要是為了在集群環(huán)境中提示W(wǎng)eblogic Server session中的值發(fā)生了改變，需要向其他服務(wù)器進(jìn)程復(fù)制新的session值。

　　10、為什么session不見了

　　排除session正常失效的因素之外，服務(wù)器本身的可能性應(yīng)該是微乎其微的，雖然筆者在iPlanet6SP1加若干補(bǔ)丁的Solaris版本上倒也遇到過；瀏覽器插件的可能性次之，筆者也遇到過3721插件造成的問題；理論上防火墻或者代理服務(wù)器在cookie處理上也有可能會(huì)出現(xiàn)問題。

　　出現(xiàn)這一問題的大部分原因都是程序的錯(cuò)誤，最常見的就是在一個(gè)應(yīng)用程序中去訪問另外一個(gè)應(yīng)用程序。我們?cè)谙乱还?jié)討論這個(gè)問題。

　　七、跨應(yīng)用程序的session共享

　　常常有這樣的情況，一個(gè)大項(xiàng)目被分割成若干小項(xiàng)目開發(fā)，為了能夠互不干擾，要求每個(gè)小項(xiàng)目作為一個(gè)單獨(dú)的web應(yīng)用程序開發(fā)，可是到了最后突然發(fā)現(xiàn)某幾個(gè)小項(xiàng)目之間需要共享一些信息，或者想使用session來實(shí)現(xiàn)SSO(single sign on)，在session中保存login的用戶信息，最自然的要求是應(yīng)用程序間能夠訪問彼此的session。

　　然而按照Servlet規(guī)范，session的作用范圍應(yīng)該僅僅限于當(dāng)前應(yīng)用程序下，不同的應(yīng)用程序之間是不能夠互相訪問對(duì)方的session的。各個(gè)應(yīng)用服務(wù)器從實(shí)際效果上都遵守了這一規(guī)范，但是實(shí)現(xiàn)的細(xì)節(jié)卻可能各有不同，因此解決跨應(yīng)用程序session共享的方法也各不相同。

　　首先來看一下Tomcat是如何實(shí)現(xiàn)web應(yīng)用程序之間session的隔離的，從Tomcat設(shè)置的cookie路徑來看，它對(duì)不同的應(yīng)用程序設(shè)置的cookie路徑是不同的，這樣不同的應(yīng)用程序所用的session id是不同的，因此即使在同一個(gè)瀏覽器窗口里訪問不同的應(yīng)用程序，發(fā)送給服務(wù)器的session id也可以是不同的。

　　根據(jù)這個(gè)特性，我們可以推測(cè)Tomcat中session的內(nèi)存結(jié)構(gòu)大致如下。

　　筆者以前用過的iPlanet也采用的是同樣的方式，估計(jì)SunONE與iPlanet之間不會(huì)有太大的差別。對(duì)于這種方式的服務(wù)器，解決的思路很簡(jiǎn)單，實(shí)際實(shí)行起來也不難。要么讓所有的應(yīng)用程序共享一個(gè)session id，要么讓應(yīng)用程序能夠獲得其他應(yīng)用程序的session id。

　　iPlanet中有一種很簡(jiǎn)單的方法來實(shí)現(xiàn)共享一個(gè)session id，那就是把各個(gè)應(yīng)用程序的cookie路徑都設(shè)為/（實(shí)際上應(yīng)該是/NASApp，對(duì)于應(yīng)用程序來講它的作用相當(dāng)于根）。

/NASApp

　　需要注意的是，操作共享的session應(yīng)該遵循一些編程約定，比如在session attribute名字的前面加上應(yīng)用程序的前綴，使得setAttribute("name", "neo")變成setAttribute("app1.name", "neo")，以防止命名空間沖突，導(dǎo)致互相覆蓋。

　　在Tomcat中則沒有這么方便的選擇。在Tomcat版本3上，我們還可以有一些手段來共享session。對(duì)于版本4以上的Tomcat，目前筆者尚未發(fā)現(xiàn)簡(jiǎn)單的辦法。只能借助于第三方的力量，比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie，URL參數(shù)或者隱藏字段等手段。

　　我們?cè)倏匆幌耊eblogic Server是如何處理session的。

　　從截屏畫面上可以看到Weblogic Server對(duì)所有的應(yīng)用程序設(shè)置的cookie的路徑都是/，這是不是意味著在Weblogic Server中默認(rèn)的就可以共享session了呢？然而一個(gè)小實(shí)驗(yàn)即可證明即使不同的應(yīng)用程序使用的是同一個(gè)session，各個(gè)應(yīng)用程序仍然只能訪問自己所設(shè)置的那些屬性。這說明Weblogic Server中的session的內(nèi)存結(jié)構(gòu)可能如下

　　對(duì)于這樣一種結(jié)構(gòu)，在session機(jī)制本身上來解決session共享的問題應(yīng)該是不可能的了。除了借助于第三方的力量，比如使用文件、數(shù)據(jù)庫、JMS或者客戶端cookie，URL參數(shù)或者隱藏字段等手段，還有一種較為方便的做法，就是把一個(gè)應(yīng)用程序的session放到ServletContext中，這樣另外一個(gè)應(yīng)用程序就可以從ServletContext中取得前一個(gè)應(yīng)用程序的引用。示例代碼如下，

　　應(yīng)用程序A

context.setAttribute("appA", session);

　　應(yīng)用程序B

contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

　　值得注意的是這種用法不可移植，因?yàn)楦鶕?jù)ServletContext的JavaDoc，應(yīng)用服務(wù)器可以處于安全的原因?qū)τ赾ontext.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通過。

　　那么Weblogic Server為什么要把所有的應(yīng)用程序的cookie路徑都設(shè)為/呢？原來是為了SSO，凡是共享這個(gè)session的應(yīng)用程序都可以共享認(rèn)證的信息。一個(gè)簡(jiǎn)單的實(shí)驗(yàn)就可以證明這一點(diǎn)，修改首先登錄的那個(gè)應(yīng)用程序的描述符weblogic.xml，把cookie路徑修改為/appA訪問另外一個(gè)應(yīng)用程序會(huì)重新要求登錄，即使是反過來，先訪問cookie路徑為/的應(yīng)用程序，再訪問修改過路徑的這個(gè)，雖然不再提示登錄，但是登錄的用戶信息也會(huì)丟失。注意做這個(gè)實(shí)驗(yàn)時(shí)認(rèn)證方式應(yīng)該使用FORM，因?yàn)闉g覽器和web服務(wù)器對(duì)basic認(rèn)證方式有其他的處理方式，第二次請(qǐng)求的認(rèn)證不是通過session來實(shí)現(xiàn)的。具體請(qǐng)參看[7] secion 14.8 Authorization，你可以修改所附的示例程序來做這些試驗(yàn)。

　　八、總結(jié)

　　session機(jī)制本身并不復(fù)雜，然而其實(shí)現(xiàn)和配置上的靈活性卻使得具體情況復(fù)雜多變。這也要求我們不能把僅僅某一次的經(jīng)驗(yàn)或者某一個(gè)瀏覽器，服務(wù)器的經(jīng)驗(yàn)當(dāng)作普遍適用的經(jīng)驗(yàn)，而是始終需要具體情況具體分析。

以前裝過sql server，后來刪掉。現(xiàn)在重裝，卻出現(xiàn)“以前的某個(gè)程序安裝已在安裝計(jì)算機(jī)上創(chuàng)建掛起的文件操作。運(yùn)行安裝程序之前必須重新啟動(dòng)計(jì)算機(jī)”錯(cuò)誤。無法進(jìn)行下去。

參考網(wǎng)上資料，總算搞定。步驟是：

1）添加/刪除程序中徹底刪除sql server。

2）將沒有刪除的sql server目錄也刪除掉。

3）打開注冊(cè)表編輯器，在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager中找到PendingFileRenameOperations項(xiàng)目，并刪除它。這樣就可以清除安裝暫掛項(xiàng)目。

4）刪除注冊(cè)表中跟sql server相關(guān)的鍵。

其實(shí)估計(jì)只要做第3步就可以搞定，這樣就可以清除安裝暫掛項(xiàng)目。自己是先走了1，2，4，最后做了3才搞定。所以估計(jì)3才是最關(guān)鍵的。

ME too

前兩天要把我們信息平臺(tái)上的tomcat４加為服務(wù)，
         
         剛一開始就想先遷移到tomcat5上可是遷移以后數(shù)據(jù)庫總是聯(lián)不上，郁悶了好久。
后來又從網(wǎng)上找直接把tomcat4加為服務(wù)的腳本，嘗試了幾次，總是找不到tomcat的目錄，原來批處理文件里面不識(shí)別空格，把文件名改了下，服務(wù)算是加上了，可啟動(dòng)時(shí)卻總是出錯(cuò)誤，又重新裝了一次tomcat4.1.3,發(fā)現(xiàn)裝完以后在　/bin的文件夾里，根本就沒有tomcat.exe,著實(shí)有些郁悶，看來原來那個(gè)tomcat.exe肯定是從tomcat5里面拷過來的。不經(jīng)意間又裝了一遍tomcat4.1.3，發(fā)現(xiàn)有一個(gè)選項(xiàng)（NT service　xp/2000;only）郁悶啊，這不是直接就可以加為服務(wù)嗎，暈死了過去。。。。

       這說明我還是太粗心了，裝過那么多回tomcat，也想過這個(gè)ntservice，怎么就記過這就是加成服務(wù)的呢
，我說網(wǎng)上相關(guān)的東西怎么這么少，原來是apahce已經(jīng)帶了這個(gè)功能。

把以下代碼粘貼到首頁中，就可以從counter.txt中讀取訪問量。
一定要注意路徑的問題，剛開始直接用counter.txt，結(jié)果總是找不到文件，而且用絕對(duì)路徑也不行，
但是用/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();%>

<form action="submit_1.html" method=post>
<input type=image src="exa.gif" name="sub1">
</form>

就是這簡(jiǎn)單

abstract class和interface是Java語言中對(duì)于抽象類定義進(jìn)行支持的兩種機(jī)制，正是由于這兩種機(jī)制的存在，才賦予了Java強(qiáng)大的面向?qū)ο竽芰Αbstract class和interface之間在對(duì)于抽象類定義的支持方面具有很大的相似性，甚至可以相互替換，因此很多開發(fā)者在進(jìn)行抽象類定義時(shí)對(duì)于abstract class和interface的選擇顯得比較隨意。
其實(shí)，兩者之間還是有很大的區(qū)別的，對(duì)于它們的選擇甚至反映出對(duì)于問題領(lǐng)域本質(zhì)的理解、對(duì)于設(shè)計(jì)意圖的理解是否正確、合理。本文將對(duì)它們之間的區(qū)別進(jìn)行一番剖析，試圖給開發(fā)者提供一個(gè)在二者之間進(jìn)行選擇的依據(jù)。
一、理解抽象類
abstract class和interface在Java語言中都是用來進(jìn)行抽象類（本文中的抽象類并非從abstract class翻譯而來，它表示的是一個(gè)抽象體，而abstract class為Java語言中用于定義抽象類的一種方法，請(qǐng)讀者注意區(qū)分）定義的，那么什么是抽象類，使用抽象類能為我們帶來什么好處呢？
在面向?qū)ο蟮母拍钪校覀冎浪械膶?duì)象都是通過類來描繪的，但是反過來卻不是這樣。并不是所有的類都是用來描繪對(duì)象的，如果一個(gè)類中沒有包含足夠的信息來描繪一個(gè)具體的對(duì)象，這樣的類就是抽象類。抽象類往往用來表征我們?cè)趯?duì)問題領(lǐng)域進(jìn)行分析、設(shè)計(jì)中得出的抽象概念，是對(duì)一系列看上去不同，但是本質(zhì)上相同的具體概念的抽象。
比如：如果我們進(jìn)行一個(gè)圖形編輯軟件的開發(fā)，就會(huì)發(fā)現(xiàn)問題領(lǐng)域存在著圓、三角形這樣一些具體概念，它們是不同的，但是它們又都屬于形狀這樣一個(gè)概念，形狀這個(gè)概念在問題領(lǐng)域是不存在的，它就是一個(gè)抽象概念。正是因?yàn)槌橄蟮母拍钤趩栴}領(lǐng)域沒有對(duì)應(yīng)的具體概念，所以用以表征抽象概念的抽象類是不能夠?qū)嵗摹?BR>在面向?qū)ο箢I(lǐng)域，抽象類主要用來進(jìn)行類型隱藏。我們可以構(gòu)造出一個(gè)固定的一組行為的抽象描述，但是這組行為卻能夠有任意個(gè)可能的具體實(shí)現(xiàn)方式。這個(gè)抽象描述就是抽象類，而這一組任意個(gè)可能的具體實(shí)現(xiàn)則表現(xiàn)為所有可能的派生類。模塊可以操作一個(gè)抽象體。由于模塊依賴于一個(gè)固定的抽象體，因此它可以是不允許修改的；同時(shí)，通過從這個(gè)抽象體派生，也可擴(kuò)展此模塊的行為功能。熟悉OCP的讀者一定知道，為了能夠?qū)崿F(xiàn)面向?qū)ο笤O(shè)計(jì)的一個(gè)最核心的原則OCP(Open-Closed Principle)，抽象類是其中的關(guān)鍵所在。
二、從語法定義層面看abstract class和interface
在語法層面，Java語言對(duì)于abstract class和interface給出了不同的定義方式，下面以定義一個(gè)名為Demo的抽象類為例來說明這種不同。使用abstract class的方式定義Demo抽象類的方式如下：

abstract class Demo ｛ 
 abstract void method1(); 
 abstract void method2(); 
 … 
｝

使用interface的方式定義Demo抽象類的方式如下：

interface Demo { 
 void method1(); 
 void method2(); 
 … 
}

在abstract class方式中，Demo可以有自己的數(shù)據(jù)成員，也可以有非abstarct的成員方法，而在interface方式的實(shí)現(xiàn)中，Demo只能夠有靜態(tài)的不能被修改的數(shù)據(jù)成員（也就是必須是static final的，不過在interface中一般不定義數(shù)據(jù)成員），所有的成員方法都是abstract的。從某種意義上說，interface是一種特殊形式的abstract class。
從編程的角度來看，abstract class和interface都可以用來實(shí)現(xiàn)"design by contract"的思想。但是在具體的使用上面還是有一些區(qū)別的。
首先，abstract class在Java語言中表示的是一種繼承關(guān)系，一個(gè)類只能使用一次繼承關(guān)系。但是，一個(gè)類卻可以實(shí)現(xiàn)多個(gè)interface。也許，這是Java語言的設(shè)計(jì)者在考慮Java對(duì)于多重繼承的支持方面的一種折中考慮吧。
其次，在abstract class的定義中，我們可以賦予方法的默認(rèn)行為。但是在interface的定義中，方法卻不能擁有默認(rèn)行為，為了繞過這個(gè)限制，必須使用委托，但是這會(huì) 增加一些復(fù)雜性，有時(shí)會(huì)造成很大的麻煩。
在抽象類中不能定義默認(rèn)行為還存在另一個(gè)比較嚴(yán)重的問題，那就是可能會(huì)造成維護(hù)上的麻煩。因?yàn)槿绻髞硐胄薷念惖慕缑妫ㄒ话阃ㄟ^abstract class或者interface來表示）以適應(yīng)新的情況（比如，添加新的方法或者給已用的方法中添加新的參數(shù)）時(shí)，就會(huì)非常的麻煩，可能要花費(fèi)很多的時(shí)間（對(duì)于派生類很多的情況，尤為如此）。但是如果界面是通過abstract class來實(shí)現(xiàn)的，那么可能就只需要修改定義在abstract class中的默認(rèn)行為就可以了。
同樣，如果不能在抽象類中定義默認(rèn)行為，就會(huì)導(dǎo)致同樣的方法實(shí)現(xiàn)出現(xiàn)在該抽象類的每一個(gè)派生類中，違反了"one rule，one place"原則，造成代碼重復(fù)，同樣不利于以后的維護(hù)。因此，在abstract class和interface間進(jìn)行選擇時(shí)要非常的小心。
三、從設(shè)計(jì)理念層面看abstract class和interface
上面主要從語法定義和編程的角度論述了abstract class和interface的區(qū)別，這些層面的區(qū)別是比較低層次的、非本質(zhì)的。本文將從另一個(gè)層面：abstract class和interface所反映出的設(shè)計(jì)理念，來分析一下二者的區(qū)別。作者認(rèn)為，從這個(gè)層面進(jìn)行分析才能理解二者概念的本質(zhì)所在。
前面已經(jīng)提到過，abstarct class在Java語言中體現(xiàn)了一種繼承關(guān)系，要想使得繼承關(guān)系合理，父類和派生類之間必須存在"is a"關(guān)系，即父類和派生類在概念本質(zhì)上應(yīng)該是相同的。對(duì)于interface 來說則不然，并不要求interface的實(shí)現(xiàn)者和interface定義在概念本質(zhì)上是一致的，僅僅是實(shí)現(xiàn)了interface定義的契約而已。為了使論述便于理解，下面將通過一個(gè)簡(jiǎn)單的實(shí)例進(jìn)行說明。
考慮這樣一個(gè)例子，假設(shè)在我們的問題領(lǐng)域中有一個(gè)關(guān)于Door的抽象概念，該Door具有執(zhí)行兩個(gè)動(dòng)作open和close，此時(shí)我們可以通過abstract class或者interface來定義一個(gè)表示該抽象概念的類型，定義方式分別如下所示：

使用abstract class方式定義Door： 

abstract class Door { 
 abstract void open(); 
 abstract void close()； 
} 

使用interface方式定義Door： 

interface Door { 
 void open(); 
 void close(); 
}

其他具體的Door類型可以extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來好像使用abstract class和interface沒有大的區(qū)別。
如果現(xiàn)在要求Door還要具有報(bào)警的功能。我們?cè)撊绾卧O(shè)計(jì)針對(duì)該例子的類結(jié)構(gòu)呢（在本例中，主要是為了展示abstract class和interface反映在設(shè)計(jì)理念上的區(qū)別，其他方面無關(guān)的問題都做了簡(jiǎn)化或者忽略）下面將羅列出可能的解決方案，并從設(shè)計(jì)理念層面對(duì)這些不同的方案進(jìn)行分析。
解決方案一：
簡(jiǎn)單的在Door的定義中增加一個(gè)alarm方法，如下：

abstract class Door { 
 abstract void open(); 
 abstract void close()； 
 abstract void alarm(); 
} 

  
或者 

interface Door { 
 void open(); 
 void close(); 
 void alarm(); 
}

那么具有報(bào)警功能的AlarmDoor的定義方式如下：

class AlarmDoor extends Door { void open() { … } void close() { … } void alarm() { … } } 或者 class AlarmDoor implements Door ｛ void open() { … } void close() { … } void alarm() { … } ｝

這種方法違反了面向?qū)ο笤O(shè)計(jì)中的一個(gè)核心原則ISP（Interface Segregation Priciple），在Door的定義中把Door概念本身固有的行為方法和另外一個(gè)概念"報(bào)警器"的行為方法混在了一起。這樣引起的一個(gè)問題是那些僅僅依賴于Door這個(gè)概念的模塊會(huì)因?yàn)?報(bào)警器"這個(gè)概念的改變（比如：修改alarm方法的參數(shù)）而改變，反之依然。
解決方案二：
既然open、close和alarm屬于兩個(gè)不同的概念，根據(jù)ISP原則應(yīng)該把它們分別定義在代表這兩個(gè)概念的抽象類中。定義方式有：這兩個(gè)概念都使用abstract class方式定義；兩個(gè)概念都使用interface方式定義；一個(gè)概念使用abstract class方式定義，另一個(gè)概念使用interface方式定義。
顯然，由于Java語言不支持多重繼承，所以兩個(gè)概念都使用abstract class方式定義是不可行的。后面兩種方式都是可行的，但是對(duì)于它們的選擇卻反映出對(duì)于問題領(lǐng)域中的概念本質(zhì)的理解、對(duì)于設(shè)計(jì)意圖的反映是否正確、合理。我們一一來分析、說明。
如果兩個(gè)概念都使用interface方式來定義，那么就反映出兩個(gè)問題：
1、我們可能沒有理解清楚問題領(lǐng)域，AlarmDoor在概念本質(zhì)上到底是Door還是報(bào)警器？
2、如果我們對(duì)于問題領(lǐng)域的理解沒有問題，比如：我們通過對(duì)于問題領(lǐng)域的分析發(fā)現(xiàn)AlarmDoor在概念本質(zhì)上和Door是一致的，那么我們?cè)趯?shí)現(xiàn)時(shí)就沒有能夠正確的揭示我們的設(shè)計(jì)意圖，因?yàn)樵谶@兩個(gè)概念的定義上（均使用interface方式定義）反映不出上述含義。
如果我們對(duì)于問題領(lǐng)域的理解是：AlarmDoor在概念本質(zhì)上是Door，同時(shí)它有具有報(bào)警的功能。我們?cè)撊绾蝸碓O(shè)計(jì)、實(shí)現(xiàn)來明確的反映出我們的意思呢？前面已經(jīng)說過，abstract class在Java語言中表示一種繼承關(guān)系，而繼承關(guān)系在本質(zhì)上是"is a"關(guān)系。所以對(duì)于Door這個(gè)概念，我們應(yīng)該使用abstarct class方式來定義。另外，AlarmDoor又具有報(bào)警功能，說明它又能夠完成報(bào)警概念中定義的行為，所以報(bào)警概念可以通過interface方式定義。如下所示：

abstract class Door { 
 abstract void open(); 
 abstract void close()； 
} 
interface Alarm { 
 void alarm(); 
} 
class AlarmDoor extends Door implements Alarm { 
 void open() { … } 
 void close() { … } 
    void alarm() { … } 
}

這種實(shí)現(xiàn)方式基本上能夠明確的反映出我們對(duì)于問題領(lǐng)域的理解，正確的揭示我們的設(shè)計(jì)意圖。其實(shí)abstract class表示的是"is a"關(guān)系，interface表示的是"like a"關(guān)系，大家在選擇時(shí)可以作為一個(gè)依據(jù)，當(dāng)然這是建立在對(duì)問題領(lǐng)域的理解上的，比如：如果我們認(rèn)為AlarmDoor在概念本質(zhì)上是報(bào)警器，同時(shí)又具有Door的功能，那么上述的定義方式就要反過來了。
abstract class和interface是Java語言中的兩種定義抽象類的方式，它們之間有很大的相似性。但是對(duì)于它們的選擇卻又往往反映出對(duì)于問題領(lǐng)域中的概念本質(zhì)的理解、對(duì)于設(shè)計(jì)意圖的反映是否正確、合理，因?yàn)樗鼈儽憩F(xiàn)了概念間的不同的關(guān)系（雖然都能夠?qū)崿F(xiàn)需求的功能）。這其實(shí)也是語言的一種的慣用法，希望讀者朋友能夠細(xì)細(xì)體會(huì)

Ant的簡(jiǎn)介：類似make工具，但可以支持多平臺(tái)
Ant的安裝：配置ant的準(zhǔn)備工作：ant_home 指Ant的安裝目錄，在path中加入%ant_home%/bin,用于命令行下
　　　　　　　　運(yùn) 行ant
Ant的結(jié)構(gòu)：主要是通過對(duì)build.xml的配置，
                     Ant內(nèi)置任務(wù)：                                                描述
                        property                                              設(shè)置name/value的屬性        
                        mkdir                                                   創(chuàng)建目錄
                        copy                                                     拷貝
                        delete                                                   刪除
                        javac                                                    編繹
                        war                                                      打包
下面是一個(gè)簡(jiǎn)單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>

從示例我們看出來，整個(gè)xml是一個(gè)project，project下有幾個(gè)為init,compile,的target
運(yùn)行時(shí)首先在這個(gè)目錄下打開dos窗口，以這個(gè)xml為準(zhǔn)，如果你只運(yùn)行ant那么只會(huì)輸出echo中的內(nèi)容
因?yàn)閜roject的default是about;　如果運(yùn)行ant complie 它會(huì)執(zhí)行兩個(gè)target: init 和complie，因?yàn)閏omplie是依靠init
的。
      用了以后發(fā)現(xiàn)ant 原來很簡(jiǎn)單，當(dāng)然現(xiàn)在只是學(xué)了個(gè)皮毛而已。

   RMI，遠(yuǎn)程方法調(diào)用（Remote Method Invocation）是Enterprise JavaBeans的支柱，是建立分布式Java應(yīng)用程序的方便途徑。RMI是非常容易使用的，但是它非常的強(qiáng)大。

       RMI的基礎(chǔ)是接口，RMI構(gòu)架基于一個(gè)重要的原理：定義接口和定義接口的具體實(shí)現(xiàn)是分開的。下面我們通過具體的例子，建立一個(gè)簡(jiǎn)單的遠(yuǎn)程計(jì)算服務(wù)和使用它的客戶程序

一個(gè)正常工作的RMI系統(tǒng)由下面幾個(gè)部分組成：

●     遠(yuǎn)程服務(wù)的接口定義

●     遠(yuǎn)程服務(wù)接口的具體實(shí)現(xiàn)

●     樁（Stub）和框架（Skeleton）文件

●     一個(gè)運(yùn)行遠(yuǎn)程服務(wù)的服務(wù)器

●     一個(gè)RMI命名服務(wù)，它允許客戶端去發(fā)現(xiàn)這個(gè)遠(yuǎn)程服務(wù)

●     類文件的提供者（一個(gè)HTTP或者FTP服務(wù)器）

●     一個(gè)需要這個(gè)遠(yuǎn)程服務(wù)的客戶端程序

下面我們一步一步建立一個(gè)簡(jiǎn)單的RMI系統(tǒng)。首先在你的機(jī)器里建立一個(gè)新的文件夾，以便放置我們創(chuàng)建的文件，為了簡(jiǎn)單起見，我們只使用一個(gè)文件夾存放客戶端和服務(wù)端代碼，并且在同一個(gè)目錄下運(yùn)行服務(wù)端和客戶端。

如果所有的RMI文件都已經(jīng)設(shè)計(jì)好了，那么你需要下面的幾個(gè)步驟去生成你的系統(tǒng)：

1、  編寫并且編譯接口的Java代碼

2、  編寫并且編譯接口實(shí)現(xiàn)的Java代碼

3、  從接口實(shí)現(xiàn)類中生成樁（Stub）和框架（Skeleton）類文件

4、  編寫遠(yuǎn)程服務(wù)的主運(yùn)行程序

5、  編寫RMI的客戶端程序

6、  安裝并且運(yùn)行RMI系統(tǒng)


1、  接口

第一步就是建立和編譯服務(wù)接口的Java代碼。這個(gè)接口定義了所有的提供遠(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;
}
注意，這個(gè)接口繼承自Remote，每一個(gè)定義的方法都必須拋出一個(gè)RemoteException異常對(duì)象。

建立這個(gè)文件，把它存放在剛才的目錄下，并且編譯。

>javac Calculator.java

2、  接口的具體實(shí)現(xiàn)

下一步，我們就要寫遠(yuǎn)程服務(wù)的具體實(shí)現(xiàn)，這是一個(gè)CalculatorImpl類文件：

//CalculatorImpl.java
//Implementation
import java.rmi.server.UnicastRemoteObject

public class CalculatorImpl extends UnicastRemoteObject implements Calculator
{

    // 這個(gè)實(shí)現(xiàn)必須有一個(gè)顯式的構(gòu)造函數(shù)，并且要拋出一個(gè)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;
    }
}
       同樣的，把這個(gè)文件保存在你的目錄里然后編譯他。

       這個(gè)實(shí)現(xiàn)類使用了UnicastRemoteObject去聯(lián)接RMI系統(tǒng)。在我們的例子中，我們是直接的從UnicastRemoteObject這個(gè)類上繼承的，事實(shí)上并不一定要這樣做，如果一個(gè)類不是從UnicastRmeoteObject上繼承，那必須使用它的exportObject()方法去聯(lián)接到RMI。

       如果一個(gè)類繼承自UnicastRemoteObject，那么它必須提供一個(gè)構(gòu)造函數(shù)并且聲明拋出一個(gè)RemoteException對(duì)象。當(dāng)這個(gè)構(gòu)造函數(shù)調(diào)用了super()，它久激活UnicastRemoteObject中的代碼完成RMI的連接和遠(yuǎn)程對(duì)象的初始化。



3、  樁（Stubs）和框架（Skeletons）

下一步就是要使用RMI編譯器rmic來生成樁和框架文件，這個(gè)編譯運(yùn)行在遠(yuǎn)程服務(wù)實(shí)現(xiàn)類文件上。

>rmic CalculatorImpl

在你的目錄下運(yùn)行上面的命令，成功執(zhí)行完上面的命令你可以發(fā)現(xiàn)一個(gè)Calculator_stub.class文件，如果你是使用的Java2SDK，那么你還可以發(fā)現(xiàn)Calculator_Skel.class文件。



4、  主機(jī)服務(wù)器

遠(yuǎn)程RMI服務(wù)必須是在一個(gè)服務(wù)器中運(yùn)行的。CalculatorServer類是一個(gè)非常簡(jiǎn)單的服務(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();
   }
}
       建立這個(gè)服務(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);
        }
    }
}
       保存這個(gè)客戶端程序到你的目錄下（注意這個(gè)目錄是一開始建立那個(gè)，所有的我們的文件都在那個(gè)目錄下），并且編譯他。



6、  運(yùn)行RMI系統(tǒng)

現(xiàn)在我們建立了所有運(yùn)行這個(gè)簡(jiǎn)單RMI系統(tǒng)所需的文件，現(xiàn)在我們終于可以運(yùn)行這個(gè)RMI系統(tǒng)啦！來享受吧。

我們是在命令控制臺(tái)下運(yùn)行這個(gè)系統(tǒng)的，你必須開啟三個(gè)控制臺(tái)窗口，一個(gè)運(yùn)行服務(wù)器，一個(gè)運(yùn)行客戶端，還有一個(gè)運(yùn)行RMIRegistry。

首先運(yùn)行注冊(cè)程序RMIRegistry，你必須在包含你剛寫的類的那么目錄下運(yùn)行這個(gè)注冊(cè)程序。

>rmiregistry

好，這個(gè)命令成功的話，注冊(cè)程序已經(jīng)開始運(yùn)行了，不要管他，現(xiàn)在切換到另外一個(gè)控制臺(tái)，在第二個(gè)控制臺(tái)里，我們運(yùn)行服務(wù)器CalculatorService，因?yàn)镽MI的安全機(jī)制將在服務(wù)端發(fā)生作用,所以你必須增加一條安全策略。以下是對(duì)應(yīng)安全策略的例子
grant {
permission java.security.AllPermission "", "";
};
注意:這是一條最簡(jiǎn)單的安全策略,它允許任何人做任何事,對(duì)于你的更加關(guān)鍵性的應(yīng)用,你必須指定更加詳細(xì)安全策略。
現(xiàn)在為了運(yùn)行服務(wù)端，你需要除客戶類(CalculatorClient.class)之外的所有的類文件。確認(rèn)安全策略在policy.txt文件之后,使用如下命令來運(yùn)行服務(wù)器。
> java -Djava.security.policy=policy.txt CalculatorServer

這個(gè)服務(wù)器就開始工作了，把接口的實(shí)現(xiàn)加載到內(nèi)存等待客戶端的聯(lián)接。好現(xiàn)在切換到第三個(gè)控制臺(tái)，啟動(dòng)我們的客戶端。
為了在其他的機(jī)器運(yùn)行客戶端程序你需要一個(gè)遠(yuǎn)程接口(Calculator.class) 和一個(gè)stub(CalculatorImpl_Stub.class)。 使用如下命令運(yùn)行客戶端
prompt> java -Djava.security.policy=policy.txt CalculatorClient

如果所有的這些都成功運(yùn)行，你應(yīng)該看到下面的輸出：

1
9
18
3
如果你看到了上面的輸出，恭喜你，你成功了，你已經(jīng)成功的創(chuàng)建了一個(gè)RMI系統(tǒng)，并且使他正確工作了。即使你運(yùn)行在同一個(gè)計(jì)算機(jī)上，RMI還是使用了你的網(wǎng)絡(luò)堆棧和TCP/IP去進(jìn)行通訊，并且是運(yùn)行在三個(gè)不同的Java虛擬機(jī)上。這已經(jīng)是一個(gè)完整的RMI系統(tǒng)。

　　在一個(gè)有密碼保護(hù)的Web應(yīng)用中，正確處理用戶退出過程并不僅僅只需調(diào)用HttpSession的invalidate()方法。現(xiàn)在大部分瀏覽器上都有后退和前進(jìn)按鈕，允許用戶后退或前進(jìn)到一個(gè)頁面。如果在用戶在退出一個(gè)Web應(yīng)用后按了后退按鈕瀏覽器把緩存中的頁面呈現(xiàn)給用戶，這會(huì)使用戶產(chǎn)生疑惑，他們會(huì)開始擔(dān)心他們的個(gè)人數(shù)據(jù)是否安全。許多Web應(yīng)用強(qiáng)迫用戶退出時(shí)關(guān)閉整個(gè)瀏覽器，這樣，用戶就無法點(diǎn)擊后退按鈕了。還有一些使用javascript，但在某些客戶端瀏覽器這卻不一定起作用。這些解決方案都很笨拙且不能保證在任一情況下100%有效，同時(shí)，它也要求用戶有一定的操作經(jīng)驗(yàn)。

　　這篇文章以示例闡述了正確解決用戶退出問題的方案。作者Kevin Le首先描述了一個(gè)密碼保護(hù)Web應(yīng)用，然后以示例程序解釋問題如何產(chǎn)生并討論解決問題的方案。文章雖然是針對(duì)JSP頁面進(jìn)行闡述，但作者所闡述的概念很容易理解切能夠?yàn)槠渌鸚eb技術(shù)所采用。最后作者展示了如何用Jakarta Struts優(yōu)雅地解決這一問題。

　　大部分Web應(yīng)用不會(huì)包含象銀行賬戶或信用卡資料那樣機(jī)密的信息，但一旦涉及到敏感數(shù)據(jù)，我們就需要提供一類密碼保護(hù)機(jī)制。舉例來說，一個(gè)工廠中工人通過Web訪問他們的時(shí)間安排、進(jìn)入他們的訓(xùn)練課程以及查看他們的薪金等等。此時(shí)應(yīng)用SSL(Secure Socket Layer)有點(diǎn)殺雞用牛刀的感覺，但不可否認(rèn)，我們又必須為這些應(yīng)用提供密碼保護(hù)，否則，工人（也就是Web應(yīng)用的使用者）可以窺探到工廠中其他雇員的私人機(jī)密信息。

　　與上述情形相似的還有位處圖書館、醫(yī)院等公共場(chǎng)所的計(jì)算機(jī)。在這些地方，許多用戶共同使用幾臺(tái)計(jì)算機(jī)，此時(shí)保護(hù)用戶的個(gè)人數(shù)據(jù)就顯得至關(guān)重要。設(shè)計(jì)良好編寫優(yōu)秀的應(yīng)用對(duì)用戶專業(yè)知識(shí)的要求少之又少。

　　我們來看一下現(xiàn)實(shí)世界中一個(gè)完美的Web應(yīng)用是如何表現(xiàn)的：一個(gè)用戶通過瀏覽器訪問一個(gè)頁面。Web應(yīng)用展現(xiàn)一個(gè)登陸頁面要求用戶輸入有效的驗(yàn)證信息。用戶輸入了用戶名和密碼。此時(shí)我們假設(shè)用戶提供的身份驗(yàn)證信息是正確的，經(jīng)過了驗(yàn)證過程，Web應(yīng)用允許用戶瀏覽他有權(quán)訪問的區(qū)域。用戶想退出時(shí)，點(diǎn)擊退出按鈕，Web應(yīng)用要求用戶確認(rèn)他是否則真的需要退出，如果用戶確定退出，Session結(jié)束，Web應(yīng)用重新定位到登陸頁面。用戶可以放心的離開而不用擔(dān)心他的信息會(huì)泄露。另一個(gè)用戶坐到了同一臺(tái)電腦前，他點(diǎn)擊后退按鈕，Web應(yīng)用不應(yīng)該出現(xiàn)上一個(gè)用戶訪問過的任何一個(gè)頁面。事實(shí)上，Web應(yīng)用在第二個(gè)用戶提供正確的驗(yàn)證信息之前應(yīng)當(dāng)一直停留在登陸頁面上。
通過示例程序，文章向您闡述了如何在一個(gè)Web應(yīng)用中實(shí)現(xiàn)這一功能。

　　JSP示例

　　為了更為有效地闡述實(shí)現(xiàn)方案，本文將從展示一個(gè)示例應(yīng)用logoutSampleJSP1中碰到的問題開始。這個(gè)示例代表了許多沒有正確解決退出過程的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作為控制器分別包含了登陸和退出代碼。

　　第二個(gè)示例應(yīng)用logoutSampleJSP2展示了如何解決示例logoutSampleJSP1中的問題。然而，第二個(gè)應(yīng)用自身也是有疑問的。在特定的情況下，退出問題還是會(huì)出現(xiàn)。

　　第三個(gè)示例應(yīng)用logoutSampleJSP3在第二個(gè)示例上進(jìn)行了改進(jìn)，比較完善地解決了退出問題。

　　最后一個(gè)示例logoutSampleStruts展示了Struts如何優(yōu)美地解決登陸問題。

　　注意：本文所附示例在最新版本的Microsoft Internet Explorer (IE), Netscape Navigator, Mozilla, FireFox和Avant瀏覽器上測(cè)試通過。

　　Login action

　　Brian Pontarelli的經(jīng)典文章《J2EE Security: Container Versus Custom》討論了不同的J2EE認(rèn)證途徑。文章同時(shí)指出，HTTP協(xié)議和基于form的認(rèn)證并未提供處理用戶退出的機(jī)制。因此，解決途徑便是引入自定義的安全實(shí)現(xiàn)機(jī)制。

　　自定義的安全認(rèn)證機(jī)制普遍采用的方法是從form中獲得用戶輸入的認(rèn)證信息，然后到諸如LDAP (lightweight directory access protocol)或關(guān)系數(shù)據(jù)庫的安全域中進(jìn)行認(rèn)證。如果用戶提供的認(rèn)證信息是有效的，登陸動(dòng)作往HttpSession對(duì)象中注入某個(gè)對(duì)象。HttpSession存在著注入的對(duì)象則表示用戶已經(jīng)登陸。為了方便讀者理解，本文所附的示例只往HttpSession中寫入一個(gè)用戶名以表明用戶已經(jīng)登陸。清單1是從loginAction.jsp頁面中節(jié)選的一段代碼以此闡述登陸動(dòng)作：

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); //...

　　本文所附示例均以關(guān)系型數(shù)據(jù)庫作為安全域，但本文所闡述的觀點(diǎn)對(duì)任何類型的安全域都是適用的。

　　Logout action

　　退出動(dòng)作就包含了簡(jiǎn)單的刪除用戶名以及對(duì)用戶的HttpSession對(duì)象調(diào)用invalidate()方法。清單2是從loginoutAction.jsp頁面中節(jié)選的一段代碼以此闡述退出動(dòng)作：

Listing 2 //... session.removeAttribute("User"); session.invalidate(); //...

Beanutils用了魔術(shù)般的反射技術(shù)，實(shí)現(xiàn)了很多夸張有用的功能，都是C/C++時(shí)代不敢想的。無論誰的項(xiàng)目，始終一天都會(huì)用得上它。我算是后知后覺了，第一回看到它的時(shí)候居然錯(cuò)過。

1.屬性的動(dòng)態(tài)getter,setter

在這框架滿天飛的年代，不能事事都保證執(zhí)行g(shù)etter,setter函數(shù)了，有時(shí)候?qū)傩允且枰鶕?jù)名字動(dòng)態(tài)的取得的，就像這樣：

　　
BeanUtils.getProperty(myBean,"code");

BeanUtils.getProperty(orderBean, "address.city");

其他類庫的BeanUtils通常都很簡(jiǎn)單，不能訪問內(nèi)嵌的對(duì)象，所以經(jīng)常要用Jakata的BeanUtils替換它們。

BeanUtils還支持List和Map類型的屬性。如下面的語法即可取得顧客列表中第一個(gè)顧客的名字

BeanUtils.getProperty(orderBean, "customers[1].name");

其中BeanUtils會(huì)使用ConvertUtils類把字符串轉(zhuǎn)為Bean屬性的真正類型，方便從HttpServletRequest等對(duì)象中提取bean，或者把bean輸出到頁面。

而PropertyUtils就會(huì)原色的保留Bean原來的類型。

2.beanCompartor 動(dòng)態(tài)排序

還是通過反射，動(dòng)態(tài)設(shè)定Bean按照哪個(gè)屬性來排序，而不再需要在bean的Compare接口進(jìn)行復(fù)雜的條件判斷。 List peoples = ...; // Person對(duì)象的列表 Collections.sort(peoples, new BeanComparator("age")); }}} 如果要支持多個(gè)屬性的復(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);

   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);

ConvertUtilsBean convertUtils = new ConvertUtilsBean();
    DateConverter dateConverter = new DateConverter();
    convertUtils.register(dateConverter,Date.class);
     //因?yàn)橐?cè)converter,所以不能再使用BeanUtils的靜態(tài)方法了，必須創(chuàng)建BeanUtilsBean實(shí)例 
     BeanUtilsBean beanUtils = new BeanUtilsBean(convertUtils,new PropertyUtilsBean());      
     beanUtils.setProperty(bean, name, value);

!4 其他功能 

4.1 PropertyUtils，當(dāng)屬性為Collection,Map時(shí)的動(dòng)態(tài)讀取：
 
Collection: 提供index
{{{   BeanUtils.getIndexedProperty(orderBean,"items",1);

  BeanUtils.getIndexedProperty(orderBean,"items[1]");

BeanUtils.getMappedProperty(orderBean, "items","111");//key-value goods_no=111 

BeanUtils.getMappedProperty(orderBean, "items(111)");

     public static Class getPropertyType(Object bean, String name)

      public static Object invokeConstructor(Class klass, Object arg)