服务器
两种解释
1.硬件,云服务器,性能很好
2.软件层面,软件,功能是可以将本地的资源文件发布到网络上,供其他用户访问
静态资源服务器的本质:通过浏览器去输入一个网络路径,服务器需要做的事就是将该网络路径,转化解析成为本地硬盘路径,然后将该资源加以响应
静态web资源:一成不变的
动态web资源:不同人,不同时间所看到的内容各不相同(servlet)
互联网发展的早起就是静态web资源
完成一个服务器思想:
socket端口接收到(因为有两个堵塞,可以用多线程来处理与封装),按照协议拆解读入,用一个类封装好;(这个思想应该要体会到:并且利用构造器来初始化)
在类中把请求头用map来进行循环封装
响应头:按照协议写回去(固定格式),响应体:html文件读入,然后写回去,在页面上展示;
思考:此刻的路径就是模块下的路径
所以:可以直接getxxx(name)获得value
常见web服务器
javaEE规范:
不同厂家不同的处理方式影响了生态的发展,
sun定义了一个ServletRequst接口,由各个厂商实现
(也就是服务器传递过来的报文由厂家进行对sun定义的接口实现,我们只负责对接口进行操作)
Tmocat
Logs目录:日志
webapps:部署资源文件
conf:tomcat配置
bin:启停tomcat(startup)
关闭tomcat
1.执行shutdown
2.ctrl+c
部署资源
tomcat最小的单位是应用,所有的资源文件必须放置在应用中农
tomcat中设置应用方式:
在webapps下新建目录,tomcat在解析的时候就会把其当做一个应用
war包格式部署
2.虚拟映射
直接部署的含义就是将资源文件放置到webapps下,
但是在某些场景下,不希望将资源文件移动到webapps目录下,保持原样依然可以使用tomcat进行部署
1.conf/catalina/localhost
这个配置表示docBase是应用的路径(村子的地址)
如果希望访问村子里的那个人,就应该用村子路径+这个人在村子里的相对路径
可以使用文件的名字当做应用的别称,那么app35就代表了d:/app2
(上图也就是下面第二的那个情况)
xml-->虚拟地址,访问这个xml就相当于访问到虚拟地址
第一: 相当于直接将地址改为映射的地址(webapp->修改地址)
<context>就是应用的来源3处,如下(直接(目录和war包)映射(两种server.xml与卡特琳娜下写一个xml))
4.HTTP请求报文被监听者8080端口号的TTTTP/1.1 Connector监听到,将其解析成为request地域性,同时还会提供一个空的response对象
5.Connect将两个对象传递给Engine,Engine进一步将两个对象传递给Host
6.Host根据请求路径,需要查找一个/app35的应用(有三个来源),如果找到那么会将这个对象交给对应的Context进行处理
7.context拿到request对象后,去除有效路径/1.txt,拼接上docBase+1.txt形成绝对路径,查找该文件是否存在,存在响应200,不存在响应404
8.Connector读取response数据,生成响应报文
Tomcat设置
1.设置端口号
2.默认访问应用
默认访问应用可以理解为缺省应用,找不到合适的应用时,就会交给缺省应用来进行处理;
缺省应用特征:应用名为ROOT,访问的时候不需要应用名
如果你希望访问资源文件不设置应用名,直接设置资源文件所在的应用为ROOT
- 1.webapps下的ROOT删除改名,重新设置为一个ROOT
- 2.conf/Catalina'/localhost下写一个ROOT.xml
- 3.设置默认访问资源
- 如果地址指向的是一个目录,而不是一个具体的文件,在访问的时候访问为默认欢迎页面,该页面在conf/web.xml文件中配置
通过IP地址直接访问到资源文件:
-
修改端口号80-->设置ROOT文件(默认访问地址)-->设置index文件(默认访问资源)
类加载器:
BootStrap类加载器:加载jdk的核心类库
Extension类加载器:加载re/ext目录下的类库
System类加载器:通过加载指令-classpath指定jar包到内存(导包 add as libb)
javac-classpath xxx.jar(应用中,maven本地仓库路径)
没有main方法,java指令表示开启一个jvm程序来运行class文件,但是jvm要求要有main方法,因此要将servlet放置到服务器中运行
进行部署资源
此时如果直接将servlet放置到应用之中,通过访问静态资源的方式访问,发现是下载而不是运行
此时存在两个问题
1.直接通过相对路径关系是下载而不是运行
2.如果能够将服务器上的代码下载,此时服务器非常危险
应用中需要设置一个WEB-INF目录,凡是该目录下的文件,都不允许被浏览器直接访问到
此时依然没有解决运行servlet的问题
暗号:取一个路径,只要客户端访问/servlet1,那么就意味着需要访问当前的servlet,就会运行servlet
1.需要将class相关文件存放在WEB-INF/classes目录下
2.如果此时还需要有其他jar包的支持,把jar包需要放置在WEB-INF/lib目录下,如果没有,则不用管
3.需要在WEB-INF目录下配置一个web.xml文件,在里面配置/servlet1--FirstServlet映射关系
如果访问root,那么不打文件资源名字就是默认访问root,(root里是映射地址)
如果改为app35,那么就要访问这个app35,里面有真实路径的映射,在真实路径里面再访问其他文件
总结:卡特琳娜下的root.xml表示(不输入资源名默认访问这里),然后在root里写上一个真实访问路径,用来做虚拟映射;
在对应映射路径下,有index就先访问index;(因为直接运行class文件就是下载,所以指定一个规则)需要有一个WEB-INF与classes文件(表示禁止直接访问,需要通过映射关系)映射关系通过WEB-INF下的web.xml文件里进行配置,真实路径与映射文件名
(WEB-INF下classes的文件就一定是已经在村里的位置了,所以直接用名字映射就找得到)
(所以之后在idea里只要把所有的SRC下的class文件移动到out目录下的classes文件里面,就可以表示访问而不是下载了)
执行方法的过程:
通过web.xml里面的映射关系,(全类名),经过反射得到对应的文件,(因为继承了servlet)调用Servlet的service方法,service方法执行的时候,将之前一致传递的两个参数request,response作为参数传递进去执行
执行代码对response和request操作(可以往response塞入数据)
动态-->指每次刷新都会执行一次java程序
使用idea(ee项目的生成,配置tomcat)
事实证明上面二者都不是,以及server.xml也不是 (看最后)
这个表示访问servlet2就会映射到上面那个全类名
真实路径是idea的模块所在的路径
servlet方法是整个程序的入口,就是一定会执行
在继承httpServlet中依然执行的是service方法,此时首先会进行向下转型,调用另外一个(自己的httpServlet)service方法,在方法中会根据 请求方法的不同进一步调用doXXX,如果是get方法,那么会调用getXXX
针对暗号的方式,还可以通过注解的方式进行改进
@serverlet
IDEA和Servlet的关联
都不是以上三者 ,
在日志文件中发现
可以理解为idea会复制一个tomcat的配置文件到这里,然后利用这些配置文件重新开启一个新的tmocat
在新tomcat的包下有
1.卡特琳娜下有一个xml(path来自idea设置的虚拟路径),真实路径是idea下工作空间的out下的应用
2.work目录下存放着index.jsp.java与class文件(目前发现不重要)
利用这个tomcat来进行部署资源
(也就是部署了一个新的tomcat,里面有index.jsp.java,还有虚拟部署指向的工作空间下的文件,也就是out的下的真实工作应用)
以下解释了把所有编译文件与web文件都存放到out下的过程(out,web,src同级,但是编译后的文件都会由下面的方式存放到真实的工作应用之下)
下图是out下的web里面的文件,发现所有class文件都到inf里了
1.模块的地址
2.模块之下out的地址
3.最后在tomcat文件里面的虚拟映射是通过base路径
也就是复制的tomcat之下,conf之下卡特琳娜里面的xml指向的(CSServlet_war_exploded),idea工作空间的路径;
变色:
idea解决的两个问题
1.真实tomcat路径:复制了一个tomcat到base路径下,里面卡特琳娜的xml指向out下的真实工作应用
2.web文件路径:就是idea模块下的路径,然后在模块下指定一个out目录来存放编译之后的class文件
3.意义:这样可以保护文件真实路径?因为从一个路径指向了真实存放资源的路径,第一个路径里只有一个xml文件?