01.application對象的作用域范圍是整個應用服務，而它在應用中所承擔的責任就類似于一個全局變量。只要服務啟動，則application對象就會存在。
02.在一個應用中只有一個application，每一個用戶都會共享這一個application對象。
03.通過統計網站訪問次數來講解application的用法
解析：cookie是Web服務器保存在客戶端的一系列文本信息，根據域名和端口號區分是否保存成一個文件，文件大小為4k。注意:http://localhost:8080/news 和http://localhost:8080/news/util會形成兩個cookie文件。
1. 什么是cookie
瀏覽器與WEB服務器之間是使用HTTP協議進行通信的，當某個用戶發出頁面請求時，WEB服務器只是簡單的進行響應，然后就關閉與該用戶的連接。因此當一個請求發送到WEB服務器時，無論其是否是第一次來訪，服務器都會把它當作第一次來對待，這樣的不好之處可想而知。為了彌補這個缺陷，Netscape開發出了cookie這個有效的工具來保存某個用戶的識別信息，因此人們昵稱為“小甜餅”。cookies是一種WEB服務器通過瀏覽器在訪問者的硬盤上存儲信息的手段：Netscape Navigator使用一個名為cookies.txt本地文件保存從所有站點接收的Cookie信息；而IE瀏覽器把Cookie信息保存在類似于C:/windows/cookies的目錄下。當用戶再次訪問某個站點時，服務端將要求瀏覽器查找并返回先前發送的Cookie信息，來識別這個用戶。
2.使用Cookie
解析：
獲取指定key值cookie的核心代碼
<%
Cookie[] cookies = request.getCookies();
if(cookies!=null){
for(int i=0;i<cookies.length;i++){
if(cookies[i].getName().equals("uname")){
response.sendRedirect(path+"/welcome.jsp");
}
}
}
%>
3.javaBean
解析：從JavaBean的功能上可以分為封裝數據和封裝業務的JavaBean
一個JavaBean至少符合以下條件
01.是一個公有類
02.屬性私有
03.有getter和setter方法
04.無參的公有構造
TTP協議是無狀態的，即信息無法通過HTTP協議本身進傳遞。為了跟蹤用戶的操作狀態，asp應用SESSION對象。JSP使用一個叫HttpSession的對象實現同樣的功能。HTTPSession 是一個建立在cookies 和URL-rewriting上的高質量的界面。Session的信息保存在服務器端，Session的id保存在客戶機的cookie中。事實上，在許多服務器上，如果瀏覽器支持的話它們就使用cookies,但是如果不支持或廢除了的話就自動轉化為URL-rewriting，session自動為每個流程提供了方便地存儲信息的方法。
Session一般在服務器上設置了一個30分鐘的過期時間，當客戶停止活動后自動失效。Session 中保存和檢索的信息不能是基本數據類型如 int, double等，而必須是java的相應的對象,如Integer, Double。
Httpsession具有如下API:
getId 此方法返回唯一的標識，這些標識為每個session而產生。當只有一個單一的值與一個session聯合時，或當日志信息與先前的sessions有關時，它被當作鍵名用。
GetCreationTime 返回session被創建的時間。最小單位為千分之一秒。為得到一個對打印輸出很有用的值，可將此值傳給Date constructor 或者GregorianCalendar的方法setTimeInMillis。
GetLastaccessedTime 返回session最后被客戶發送的時間。最小單位為千分之一秒。
GetMaxInactiveInterval 返回總時間（秒）,負值表示session永遠不會超時。
getAttribute 取一個session相聯系的信息。（在jsp1.0中為 getValue）
Integer item = (Integer) session.getAttrobute("item") //檢索出session的值并轉化為整型
setAttribute 提供一個關鍵詞和一個值。會替換掉任何以前的值。(在jsp1.0中為putValue)
session.setAttribute("ItemValue", itemName); // ItemValue 必須不是must簡單類型
在應用中使用最多的是getAttribute和setAttribute?，F以一個簡單的例子來說明session的應用， test1.jsp(信息寫入session),test2.jsp(從session讀出信息)。
1 test1.jsp 2 3 ＜HTML＞ 4 5 ＜HEAD＞ 6 7 ＜TITLE＞ Document ＜/TITLE＞ 8 9 ＜/HEAD＞10 11 ＜BODY BGCOLOR="#FFFFFF"＞12 session.setAttribute("str",new String(“this is test”));13 ＜/BODY＞14 15 ＜/HTML＞16 test2.jsp17 ＜HTML＞18 19 ＜HEAD＞20 ＜TITLE＞ New Document ＜/TITLE＞21 22 ＜/HEAD＞23 24 ＜BODY BGCOLOR="#FFFFFF"＞25 ＜%26 String ls_str=null;27 ls_str=(String)session.getAttribute("str");28 out.PRintln(“從session里取出的值為：”+ls_str);29 %＞30 ＜/BODY＞31 32 ＜/HTML＞
只要能處理客戶端請求的類都可以看成Servlet。
解析: HttpServletRequest接口中方法更容易操作,而ServletRequest應用場景更廣一些(可以處理任何協議請求).
servlet是和jsp并行的兩套用于開發動態web網站的技術
解析：Servlet就是一個實現了特定接口或者父類的java類。
Servlet 是一個 Java程序，是在服務器上(Tomcat容器中)運行以處理客戶端請求并做出響應的程序.Servlet的職責就是接收客戶端的請求并且對請求作出響應.
01.Servlet接口：5個方法
init(){
//初始化
}
service(){
//處理請求
}
//泥石流摧毀了整個村莊
destory(){
//銷毀
}
getServletConfig(){
//獲取Servlet配置信息
}
getServletInfo(){
//獲取Servlet相關信息，例如版本作者等。
}
5個方法: init():初始化，只被執行一次
Destory():tomcat關閉的時候執行，釋放資源，執行一次
Service():處理客戶端請求，并且對客戶端請求作出相應
getServletConfig():獲取配置
getServletInfo():版本等信息
02.實現GenericServlet抽象類
修改了Servlet類一定要重啟服務器,而修改了jsp頁面可以不重啟
03.實現HttpServlet抽象類
service():調度作用
//如果我們自己的Servlet類繼承的是HttpServlet抽象類,那么不用重寫父類的service(),service()方法只不過是起到一個調度的作用
doXXX:doPost(HttpServletRequest request,HttpServletResponse response ) doGet()
01.Servlet就是運行在服務器端的能夠處理客戶端請求的一個java類，如果一個
普通類實現了Servlet接口或者是繼承自GenericServlet或者繼承自HttpServlet，那么該類就變成了一個Servlet
02.如果類實現的是Servlet接口，那么處理請求的就是service()方法
如果類繼承的是HttpServlet抽象類， 那么處理請求的是doGet()和doPost()方法，這里
service()只是調度的作用。
ServletContext我們可以將ServletContext看做是一個全局的變量，類似于jsp中的
appliction對象。
URI：統一資源標識符，抽象的資源標識方法。
URL：統一資源定位符，不僅僅標識一個資源，而且還指定了如何定位到該資源。
生命周期：
在程序執行的某個特定時刻必然會執行的代碼
出生:洗澡!!!! 20-30歲結婚 80歲死亡
如何偷懶？？
請注意聽下面2分鐘
修改Serverlet的模板
在common文件夾的插件文件夾（plugins）下找到
com.genuitec.eclipse.wizards_9.0.0.me201108091322.jar
解析:和jsp中一模一樣
解析：request.getSession().setAttribute(name, value)
解析:servlet中的init()和destory()只會被執行一次,客戶端每次訪問相應的Servlet類,都會調用一次service() （重點）
獲取方案：
Servlet初始化參數：
Servlet初始化參數定義在web.xml中的一個servlet元素中，例如：
<servlet>
<servlet-name>test</servlet-name>
<servlet-class>com.bk.Test</servlet-class>
<init-param>
<param-name>default-time</param-name>
<param-value>60</param-value>
</init-param>
</servlet>
可以有若干個<init-param>對。
怎樣取得Servlet初始化參數？
A 單個參數值的獲取
通過ServletConfig接口的getInitParameter(java.lang.String name)方法。
getServletConfig()該方法定義在Servlet接口中，返回ServletConfig接口的引用。
所有的servlet都繼承了該方法。當容器實例化一個servlet之前，會從web.xml中讀取這個servlet的初始化參數，并把這些參數交給ServletConfig，然后在調用init()方法時，容器會傳送這個ServletConfig的引用到servlet。每個servlet都會有一個唯一的ServletConfig引用。一旦有了ServletConfig的引用就可以調用getInitParameter()方法來
取得我們在servlet中設置的初始化參數。
2 獲取方式：
public void service(ServletRequest req,ServletResponse res) throws
ServletException,IOException{
...
out.println("init parameters");
Enumeration myEnum=getInitParameterNames();
while(myEnum.hasMoreElements()){
String name=(String)myEnum.nextElement();//取得參數名
out.println(name+":"+getInitParameter(name));//獲取參數值
}
...
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
上下文初始化參數：
上下文初始化參數與Servlet初始化參數類似，區別是上下文初始化參數對整個web應用而不是Servlet初
始化參數只對應一個servlet。
在web應用的整個生命周期中上下文初始化參數都存在，任意的servlet和jsp都可以隨時隨地的訪問它。
在web.xml中的配置例子如下：
<context-param>
<param-name>default-time</param-name>
<param-value>60</param-value>
</context-param>
上下文初始化參數對應于整個web應用，因此它不在某個servlet元素內。一個web應用有一個ServletContext，而一個servlet有一個ServletConfig。
怎樣取得上下文初始化參數？
servlet的ServletConfig對象擁有該servlet的ServletContext的一個引用，所以可這樣取得上下文初始化參數；
getServletConfig().getServletContext().getInitParameter()
也可以在servlet中直接調用getServletContext().getInitParameter(),兩者是等價的。
mvc：model（模型），view（視圖）和 controller（控制器）
01.所有的請求都歸結到控制器(Controller)，今天的Servlet充當控制器的角色
只做解析請求(拆解request的各個屬性)并且給出響應(轉發確定交給哪一個jsp頁面去渲染視圖)
HTTP協議本身是無狀態的，這與HTTP協議本來的目的是相符的，客戶端只需要簡單的向服務器請求下載某些文件，無論是客戶端還是服務器都沒有必要記錄彼此過去的行為，每一次請求之間都是獨立的，好比一個顧客和一個自動售貨機或者一個普通的（非會員制）大賣場之間的關系一樣。
然而聰明（或者貪心？）的人們很快發現如果能夠提供一些按需生成的動態信息會使web變得更加有用，就像給有線電視加上點播功能一樣。這種需求一方 面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為，另一方面在服務器端則出現了CGI規范以響應客戶端的動態請求，作為傳輸載體的HTTP協議也 添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協議無狀態的缺陷所作出的努力。至于后來出現的session機制則 是又一種在客戶端與服務器之間保持狀態的解決方案。
讓我們用幾個例子來描述一下cookie和session機制之間的區別與聯系。筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來記錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案：
1、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎么對待了。這種做法就是協議本身支持狀態。
2、發給顧客一張卡片，上面記錄著消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以后的消費相聯系起來。這種做法就是在客戶端保持狀態。
3、發給顧客一張會員卡，除了卡號之外什么信息也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店里的紀錄本上找到這個卡號對應的紀錄添加一些消費信息。這種做法就是在服務器端保持狀態。
由于HTTP協議是無狀態的，而出于種種考慮也不希望使之成為有狀態的，因此，后面兩種方案就成為現實的選擇。具體來說cookie機制采用的是在 客戶端保持狀態的方案，而session機制采用的是在服務器端保持狀態的方案。同時我們也看到，由于采用服務器端保持狀態的方案在客戶端也需要保存一個 標識，所以session機制可能需要借助于cookie機制來達到保存標識的目的，但實際上它還有其他選擇。
Java Servlet API 中引用 Session 機制來追蹤客戶的狀態。Servlet API 中定義了 javax.servlet.http.HttpSession 接口，Servlet 容器必須實現這個接口。當一個 Session 開始時，Servlet 容器將創建一個 HttpSession 對象，Servlet 容器為 HttpSession 分配一個唯一標識符，稱為 Session ID。Servlet 容器將 Session ID 作為 Cookie 保存在客戶的瀏覽器中。每次客戶發出 HTTP 請求時，Servlet 容器可以從 HttpRequest 對象中讀取 Session ID，然后根據 Session ID 找到相應的 HttpSession 對象，從而獲取客戶的狀態信息。
當客戶端瀏覽器中禁止 Cookie，Servlet 容器無法從客戶端瀏覽器中取得作為 Cookie 的 Session ID，也就無法跟蹤客戶狀態。
Java Servlet API 中提出了跟蹤 Session 的另一種機制，如果客戶端瀏覽器不支持 Cookie，Servlet 容器可以重寫客戶請求的 URL，把 Session ID 添加到 URL 信息中。
HttpServletResponse 接口提供了重寫 URL 的方法：public java.lang.String encodeURL(java.lang.String url)
該方法的實現機制為：
● 先判斷當前的 Web 組件是否啟用 Session，如果沒有啟用 Session，直接返回參數 url。
● 再判斷客戶端瀏覽器是否支持 Cookie，如果支持 Cookie，直接返回參數 url；如果不支持 Cookie，就在參數 url 中加入 Session ID 信息，然后返回修改后的 url。
我們可以對網頁中的鏈接稍作修改，解決以上問題：
修改前：
<a href=“maillogin.jsp“>
修改后：
<a href=“<%=response.encodeURL(“maillogin.jsp“)%>“>
新聞熱點
疑難解答
