servletContext接口是Servlet中最大的一个接口,呈现了web应用的Servlet视图。ServletContext实例是经过 getServletContext()方法得到的,因为HttpServlet继承Servlet的关系GenericServlet类和HttpServlet类同时具备该方法。
条件:假设说咱们有一个WEB应用,这个WEB应用中有10个SERVLET
在这里,这个WEB应用就拥有一个它本身的仓库-ServletContext,而这10个Servlet则共享这个大仓库,而且各自拥有属于他们本身的小仓库-ServletConfig。
ServletContext就是一个全局的概念,它属于应用,但咱们有时候不想让某些参数被其余Servlet应用,仅仅想在本身的Servlet中被共享,这时候就须要把它保存在ServletConfig中,换句话说,从一个Servlet来看,ServletConfig是它的全局,而从一个Servlet集合(Web应用)来看,ServletContext是它的全局。
假设如今要运行一个应用。 web
1.Tomcat启动→读入xml文件
2.容器为这个应用创建一个新的ServletContext实例,应用的全部部分都共享这个上下文
3.若是xml中有定义上下文的初始参数,则容器首先建立初始参数实例(应该就像一个Bean同样)
4.把初始化参数实例的引用交给ServletContext
5.容器创建一个新的servlet,这时创建一个新的ServletConfig对象,而且为这个ServletConfig对象提供一个ServletContext的引用
6.调用servlet的init()方法初始化servlet session
由第5步能够看出,每一个servlet中都有一个上下文(ServletContext)的引用,所以,servlet都知道这个上下文。
可是ServletContext的实例比Servlet先诞生,因此ServletContext诞生的时候并不知道Servlet的存在。 app
在JAVA EE API文档中
ServlectContext拥有得到Servlet的方法
例如:Servlet getServlet(String name)
可是,这一类的方法已经废弃了,从注释中能够看出,原先的这些方法返回的值是null,也就是没法得到servlet
所以,ServlectContext诞生的时候并不知道Servlet的存在,它的诞生仅仅是由于容器诞生了
笔者以为,ServletContext中并无Servlet的信息,相反,每一个Servlet中都持有ServletContext的引用。
在HeadFirstJSP中有一个说法我以为不错,ServletContext就像一块布告栏,你能够往上贴布告,走过的人均可以看到它!
servlet上下文,是针对servletconfig而提出来的,由于容器在配置文件中提取的初始化参数保存在了servletconfig对象中,但因为初始化参数只针对某个具体的servlet而言,别的servlet是访问不到这个参数的,因此为了提供一个能够供全体servlet使用的对象--这个对象也能够从配置文件中获取参数,哪一个老外就弄出了一个servletcontext对象,并把它称为上下文或者应用上下文,其实就这么简单。只不过你们如今所听到的所看到的上下文被形态化了,经典话了而已。追起本质,仍是很好理解的。jsp
ServletContext 与application的异同 xml
相同:其实servletContext和application 是同样的,就至关于一个类建立了两个不一样名称的变量。在servlet中ServletContext就是application对象。你们只要打开jsp编译事后生成的Servlet中的
_jspService()方法就能够看到以下的声明:
ServletContextapplication = null;
application= pageContext.getServletContext();
不一样:二者的区别就是application用在jsp中,servletContext用在servlet中。application和page
requestsession 都是JSP中的内置对象,在后台用ServletContext存储的属性数据能够用
application对象得到。
并且application的做用域是整个Tomcat启动的过程。
例如:ServletContext.setAttribute("username",username);
则在JSP网页中可使用 application.getAttribute("username");
来获得这个用户名。对象