服务器

两种解释

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文件?

JAVA_EE(二)_WEB服务器开发相关推荐

linux服务器开发二(系统编程)--线程相关
线程概念什么是线程 LWP:Light Weight Process,轻量级的进程,本质仍是进程(在Linux环境下). 进程:独立地址空间,拥有PCB. 线程:也有PCB,但没有独立的地址空间(共 ...
Java游戏服务器开发之二--导航帖
Java游戏服务器开发之三--日志 Java游戏服务器开发之四--通讯框架netty Java游戏服务器开发之五--使用工厂模式生成netty Java游戏服务器开发之六--整合spr ...
Java游戏服务器开发之二十--xml配置文件
Java游戏服务器开发之二十--xml配置文件游戏中使用的配置文件很多像游戏中的关卡,英雄等级,装备之类都是使用配置文件(xml等) 比如有一个装备,配置表中有一条记录,数 ...
Java游戏服务器开发之十二--数据库连接整合mybatis
应该比较让人关心的还有一个就是数据存储的问题了. 下面将会介绍连接数据库的相关内容使用的是mysql数据库,框架中将使用mybatis 这里介绍时假设各位都使用或者了解过mysql. 1 ...
服务器开发和服务器应用开发_将无服务器应用程序视为“集合”并进行开发
服务器开发和服务器应用开发无服务器讲故事 (Serverless story-telling) In my previous articles on serverless, I used theme ...
ngrok服务器搭建_C/C++ Linux 后台服务器开发高级架构师学习知识路线总结
前言: 小编也是从事c方面10多年的工作经验.今天跟大家分享一下我总结出来的一系列 C/C Linux后台服务器开发的学习路线.从Linux开发工程师-Linux后台开发工程师-Linux高级互联网架 ...
这可能是东半球最保姆级的后台服务器开发学习路线
作者 | 编程指北来源 | 编程指北(id :cs_dev) 前言这一篇的主题是「Linux C/C++ 服务器/后台开发学习路线」. 这样的文章相信大家都见得不少了,写之前也非常忐忑,能不能和其 ...
服务器系统摁c,如何系统有效学习c服务器开发
学海无涯苦作舟,学习当然是一个枯燥的过程.学习c服务器开发,表面上程序漂漂亮亮风光无限,程序员是把美丽献给别人,把枯燥留给自己的职业.不过还是许多人想要学习,为此,以下是学习啦小编分享给大家的学习c服 ...
模拟linux文件系统的设计及实现_Linux后台服务器开发中，内存池设计与实现（c/c++）...
一.前言作为C++程序员,想必对于内存操作这一块是比较熟悉和操作比较频繁的: 比如申请一个对象,使用new,申请一块内存使用malloc等等: 但是,往往会有一些困扰烦恼着大家,主要体现在两部分: ...

JAVA_EE(二)_WEB服务器开发

服务器