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");
來獲得這個用戶名。對象