从功能上看分为两种:web应用服务器和java EE服务器
作用:用于检查一个boolean表达式是否正确
如果一个程序要保证其正确性,就必须使此表达式的返回值为true,返回false,则此程序有误
应用场景:通过在开发和测试中开启,在软件发布后是关闭的
限流的几种方法:计数器,滑动窗口、漏桶法、令牌桶
配置虚拟路径
此处的WEB-INF可以直接粘贴tomcat中的webapps/root/WEB-INF
配置完以后重启tomcat即可访问到
静态包含页面:<%@include file="static.jsp" %>
动态包含页面
编译过程不同
对于JSP文件首先会通过WEB服务器生成index_jsp.java(servlet文件)再经过编译生成index.class文件
request
注意事项
为什么要使用会话跟踪技术?因为服务端和客户端是通过http传输的,http是“无状态”的,一次响应完之后会断开,需要再次请求,因此需要判断是否为同一用户
JSP
Servlet
其实Jsp本质上还是Servlet(index_jsp.java),只是相比较Servlet更加视图化,而Servlet更偏向逻辑控制,其实显示用户请求以及响应的业务本质还是有Servlet实现的
index.jsp—>index_jsp.java—>index.class
getParameter():获取前端传来的参数
getAttribute(String name):返回name指定的属性值
serAttribute(String name,Object o):设置name指定的属性值
getCookies():获取cookie
getSession():获取session
getInputStream():获取输入流
<servlet>
<servlet-name>dispatcherservlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServletservlet-class>
<init-param>
<param-name>contextConfigLocationparam-name>
<param-value>classpath:applicationContext.xmlparam-value>
init-param>
<load-on-startup>1load-on-startup>
servlet>
<servlet-mapping>
<servlet-name>dispatcherservlet-name>
<url-pattern>/url-pattern>
servlet-mapping>
<servlet-mapping>
<servlet-name>defaultservlet-name>
<url-pattern>*.pngurl-pattern>
servlet-mapping>
<filter>
<filter-name>encodingFilterfilter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilterfilter-class>
<init-param>
<param-name>encodingparam-name>
<param-value>utf-8param-value>
init-param>
filter>
<filter-mapping>
<filter-name>encodingFilterfilter-name>
<url-pattern>/*url-pattern>
filter-mapping>
<session-config>
<session-timeout>30session-timeout>
session-config>
Javaweb中的监听器主要针对于application、session、request三个对象
对请求和响应进行拦截,并且按照要求进行过滤,在发送给下一个过滤器或者servlet
补充
过滤器和拦截器的区别
由图可知过滤器包含了拦截器
过滤器依赖于servlet,拦截器不依赖于servlet
过滤器是回调函数,拦截器是通过Java的反射机制
过滤器只在容器初始化的时候init一次【几乎对所有请求起作用】,而拦截器可以在action请求的生命周期中多次初始化【只对action请求起作用】
拦截器可以通过IOC容器获取各个Bean,而过滤器不行,还可以将service注入,调用业务逻辑
触发时机
(prehandler()和afterCompletion()是拦截器中的方法)
SpringMVC的机制是由同一个Servlet来分发请求给不同的Controller,其实这一步是在Servlet的service()方法中执行的
拦截器是spring容器的,是spring支持的
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1m9mLbPf-1620096675366)(Interview.assets/image-20210421085544236.png)]
总结:拦截器功在对请求权限鉴定方面确实很有用处,在我所参与的这个项目之中,第三方的远程调用每个请求都需要参与鉴定,所以这样做非常方便,而且他是很独立的逻辑,这样做让业务逻辑代码很干净。和框架的其他功能一样,原理很简单,使用起来也很简单,大致看了下SpringMVC这一部分的源码,其实还是比较容易理解的。
我们项目中仅仅用到了preHandle这个方法,而未用其他的,框架提供了一个已经实现了拦截器接口的适配器类HandlerInterceptorAdapter,继承这个类然后重写一下需要用到的方法就行了,可以少几行代码,这种方式Java中很多地方都有体现。
好家伙,这个博主也太棒了!!! https://www.cnblogs.com/panxuejun/p/7715917.html
重写Servlet中的init(),getInitParameter()获取初始化参数
getServletContext()获取上下文对象,getInitParameter()获取上下文参数
根据我们提交表单的method,如果是post,则会调用doPost(),如果是get,则会调用doGet()
因为在没有异步处理的时候,当用户端发送请求时,由servlet接受请求,经过对一些信息的预处理,开始调用接口执行业务逻辑,但此时的servlet是处于阻塞状态的,导致在高并发的情况下,性能低下,如果此时有了异步请求,在servlet阻塞的时候,会有一个子线程去执行其他任务,会将结果信息返回或者发送给其他servlet,此时不会降低性能
void init(ServletConfig var1) throws ServletException;
ServletConfig getServletConfig();
void service(ServletRequest var1, ServletResponse var2) throws ServletException, IOException;
String getServletInfo();
void destroy();
补充
什么时候实例化Servlet:
Servlet只初始化一次,即所谓的单例模式
Servlet创建之后就不会销毁,每次使用会调用Servlet的一个线程,且不会销毁;但是CGI(公共网关接口)每次调用的是一个进程,而且调用完毕后会销毁,导致开销很大
首先在容器加载时可能会创建Servlet对象或者第一次请求时,调用init();每次的请求【doPost、doGet】都会调用service(),当容器关闭时会销毁servlet,调用destroy()。对于getServletConfig()会获取Servlet的上下文或者返回ServletConfig对象;对于getServletInfo()会获取一些信息,比如作者、版权…
在第一次请求的时候调用init(),会将初始化的Servlet对象保存在内存中,在以后的每次请求中(doPost()、doGet())都会调用service(),当容器关闭时,会调用destroy(),当Servlet对象实例化时,其有关配置的初始化参数会保存在容器中,可以通过getServletConfig()获取,对于getServletInfo()可以获取有关作者,出版社等信息
对于Servlet而言,其只有创建一次,以后都会直接调用,但是对于CGI而言,每次请求都会创建一个,会不停的创建销毁,开销比较大
补充
为什么需要Servlet,因为传统的方式web容器和客户端之间只能以静态页面进行交互,因为两者是通过Http协议进行信息的传输,想要使用动态页面进行交互就要通过Servlet的支持,什么是Servlet,可以简单的理解为是一种运行于服务端的程序,狭义的理解为是Servlet接口,广义的理解为是实现Servlet接口的任何实现类,下面
以图的形式展现Servlet的作用
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0wzAgxnY-1620096675367)(Interview.assets/image-20210422221131332.png)]
在第一次请求的时候调用init(),会将初始化的Servlet对象保存在内存中,在以后的每次请求中(doPost()、doGet())都会调用service(),当容器关闭时,会调用destroy(),当Servlet对象实例化时,其有关配置的初始化参数会保存在容器中,可以通过getServletConfig()获取,对于getServletInfo()可以获取有关作者,出版社等信息
是单例模式
因为servlet是在容器加载或者第一次请求的时候初始化,直到容器关闭时才会销毁
forward:请求转发,此时的地址栏不会改变,可以共享request里面的数据,效率高
redirect:重定向,此时的地址栏会发生改变,不能共享request里面的数据,效率低
200:正确
302:重定向
404:找不到资源
500:代码错误
不对
<%@ page contentType="text/html;charset=UTF-8" language="java" %><html>
<head>
<title>$Title$title>
head>
<body>
<form method="post" action="uploadServlet" enctype="multipart/form-data">
选择文件: <input type="file" name="fileUp">
<input type="submit" value="上传">
form> ${hint}
body>
html>
@MultipartConfig@WebServlet("/uploadServlet")public class uploadServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {
Part picture = request.getPart("picture");
if (picture != null && picture.getSubmittedFileName().length() > 0) {
String realPath = request.getServletContext().getRealPath("/upload");
picture.write(realPath + "/" + picture.getSubmittedFileName());
request.setAttribute("hint", "success");
}else {
request.setAttribute("hint", "failure"); }
request.getRequestDispatcher("index.jsp").forward(request, response);
}
}
dao模式可以理解为底层模式,是持久层,是与数据库进行交互的,可以通过sql语句对数据库中的数据进行增删查改
Model
View
Controller
自定义JSP标签
jsp
post和get都可以向服务器提交数据,get是获取数数据,post是提交数据
约定俗成:
补充
因为get是将自己提交的数据,追加在url中因此不需要使用content-type,但是对于post请求是将提交的数据放在了body中,因此需要通过请求头content-type来通知服务器以什么语言来解析post中的body
常用的提交方式(content-type的值):
约定俗成:
就是一个可以提供一个接口给多个程序之间相互调用,实现其之间的通信,而且web Service并不关注你是使用何种语言的
request.setCharacterEncoding(“utf-8”);
response.setContentType(“application/json”);
response.setHeader(String,String);
区别
硬件环境不同
C/S 一般建立在专用的网络上
B/S 建立在广域网之上的,一般只要有操作系统和浏览器就行
2.对安全要求不同
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜.
可以通过B/S发布部分可公开信息。B/S 建立在广域网之上, 对安全的控制能力相对弱, 可能面向不可知的用户。
对程序架构不同
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.
B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使B/S更加成熟.
软件重用不同
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子
系统维护不同
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.
处理问题不同
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统
B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.
用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.
信息流不同
C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低
B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更像交易中心。
cookie是从服务端发出,保存在客户端的;session是保存在服务端的
cookie是不安全的可以被解析
cookie不能超过4M,并且不能多于200个
session放在服务端,当数量过多会影响服务器的性能