J2ee技術痛點

標籤：

J2ee技術痛點

1. session/cookie區別聯絡
2. jsp/servlet區別聯絡
3. filter執行流程
4. openSessionInView原理
5. clone與servilizable區別聯絡
6. equals與hashcode聯絡

1.    session與cookie

1)       瀏覽器禁用cookie後,session還能工作嗎?

可以說對和不對，需要解釋

不能使因為沒有採用url重寫機制()

實質是不能的，但是可以藉助其他手段，保證session工作，利用url重寫機制

 

保證session正常工作通常採用cookie機制，但cookie禁用後,可以利用url重寫機制保證session正常工作.

 

2)       Cookie能實現購物車功能嗎?

可以,session能乾的事情，cookie也能，因為session是通過cookie實現的

 

1.       Session與cookie的區別聯絡

(1)     Session和cookie都是儲存使用者狀態資訊的一種機制和手段

(2)     Session儲存在服務端，cookie儲存在用戶端

(3)     Session較安全，cookie安全性較差(儲存在用戶端)

(4)     Cookie可以儲存在用戶端硬碟上，可以儲存時間很長；session儲存在伺服器的內容中，儲存時間較短(tomat預設30分鐘,可以通過setMaxInactiveInterval設定最大存活時間)

(5)     Session是通過cookie的機制實現的(沒有cookie, session無法工作)

作業系統對記憶體管理方法(最近最少使用等原則)

關閉瀏覽器，session回話就消失是錯誤的，關閉瀏覽器，只能說明不在進行會話，何時銷毀有作業系統決定

利用url重寫，將sessionId放於地址後，必須保證所有頁面都是動態網頁面（靜態頁面動態化才可以）

 

2.       Session是通過cookie機制實現的

 

1）  當瀏覽器鍵入url,第一訪問伺服器時候，伺服器為請求產生唯一的標示JSESSIONID,儲存在伺服器的同時，響應用戶端瀏覽器將JSESSIONID,寫入到瀏覽器(記憶體或硬碟上)；

2）  再次請求時，請求中將用戶端的Cookie中的 JESSIONID發送給伺服器，伺服器將檢查是否是已經分配的，如果已經分配且未到期，為用戶端服務；如果未分配，產生新的SESSIONID,返回給瀏覽器，依次伺服器分配SESSIONID-à發送給瀏覽器—》瀏覽器在此請求攜帶cookie的JSESSIONID,在同一個回話中用戶端與伺服器，通過唯一標示SESSIONID是否為一個會話上下文(類似事務，或一個線程)

 

 

response.addCookie(name,value);//向用戶端添加Cookie

request.getCookie(key);//伺服器端獲得用戶端的Cookie

 

獲得用戶端請求中的Cookie

Cookie ck[] = request.getCookies();

用戶端與服務端通過JSESSIONID關鍵字標示一次會話

jessionId為32位隨機碼

 

 

通過重寫url

通過cookie方式類似，只是向伺服器傳遞資訊不通過cookie,通過url中的特定參數傳遞jsessionid

 

如:http://localhost:8088/test.jsp;jessionid=32222222222332fffffff

 

地址url中傳遞jessionid不能用普通地址參數格式傳遞

必須是url;jsessionid=…..

必須前邊是分號

*************

//地址重新格式

<%=response.encodeURL(“url”)%>

=è對應結息後方式為

http://url;jsessionid=343434343方式,這樣就可以將服務端分配的jsessionid傳遞到伺服器

無論是地址還是cookie都是為了將jsessionid資訊發送到伺服器(key:value索引值對)

 

所有地址後邊都增加都調用方法:response.encodeUrl(url),這樣相當產生的地址攜帶者jsessionid

 

 

無論是cookie還是url重新，其目的都是為向伺服器傳遞jsessionid的值

對於url重寫，response.encodeUrl(url)-à其後地址產生jsessionid參數資訊，但是此參數格式與普通不同必須是”;jsessionid=”+value格式

 

 

 

2.    Web中的相對路徑和絕對路徑

絕對路徑和相對路徑

(1)     相對路徑相對basepath(http://localhost:8080/sitename/)一定包含”/”

siteName是虛擬路徑名稱

Basepath:

   String path=request.getContextPath();

   String basePath=request.getSchema()+”://”+request.getServerName()+”:”+request.getServerPort()+path+”/”;

可以修改basePath，適應網頁相對路徑

basePath=basePath+”test/”;//basePath中包含”/”

即: http://localhost:8080/sitename/result.jsp

<base href=”<%=basePath>”/>

<form action=”result.jsp”>

</form>

可以

<form action=”test/result.jsp”>

</form>

請求地址相對於basePath

所以完整的請求路徑為

http://localhost:8080/sitename/test/result.jsp

(2)     絕對路徑

相對tomcat的根目錄而言

如果路徑最前邊增加”/”是絕對路徑

如href=”/test/a.jsp

對應請求地址為http://localhost:8080/test/a.jsp

即: http://localhost:8080/result.jsp

<form action=”/result.jsp”>

</form>

 

 

路徑上增加”/”表示絕對路徑,絕對路徑相對容器(tomcat根目錄)，不加”/”不是相對路徑(相對basepath而言)

 

(3)     當頁面不寫basePath時候，此時相對路徑為webRoot

即相對路徑，如果頁麵包含basePath就相對basePath,否則相對物理檔案夾webRoot而言

一般頁面使用相對路徑

href=”<%=request.getContextPath()%>/test/a.jsp”

request.getContextPath()=èwebsite的名字

即${website}

他是相對於物理髮布路徑而言的(webRoot)

 

 request.getContextPath()詳解

request.getContextPath()應該是得到項目的名字

<%=request.getContextPath()%>是為瞭解決相對路徑的名字的問題，可返回網站的根路徑

request.getScheme();
返回的協議名稱,預設是http

request.getServerName()
返回的是你瀏覽器中顯示的主機名稱，你自己試一下就知道了

getServerPort()
擷取伺服器連接埠號碼

如果你想得到工程檔案的實際實體路徑，可通過：<%=request.getRealPath("/")%>，這樣頁面就會輸出：d:/web。

J2ee技術痛點