标签：
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。现以一个简单的例子来说明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.jsp
17 ＜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“)%>“>
标签：
原文地址：http://www.cnblogs.com/xiaotangtang/p/4967196.html
