学技术步骤，（tomcat举例）jar包api手写tomcat静态资源基础服务器

1.看有哪些包，能用本地离线的包就使用离线包

2.尽量不要使用配置文件（先不用），能用api就用api，

因为配置文件只是文本，其实要的只是配置文件里的参数，

这些参数最后肯定还是要给到这些api去处理的，

肯定是先有api，才有的配置文件，

3.最重要的是搞清楚这个技术解决了什么问题

线程分配，并发管理，路径匹配，其实我们都能用socket和srervle自己实现，

但是我们选择用技术。。。。

因为好用

当时的tomcat搭配模板引擎技术jsp一起用，现在不用了

前后端分离，后端只关心数据，前段是数据显示和界面

jsp是数据和界面绑在一块变成html的字符串通过socket给浏览器发过去，什么前端，没有前端

4.这个技术实现了什么规范

比如Tomcat实现了javaEE的规范，那规范了点什么，我们也就要搞清楚

比如Tomcat要对接servlet，直接把request对象给到对应的servlet

而不是在servlet调Tomcat的api去取请求对象

这就是JavaEE规范的，但是tomcat也要使用者配合

这就是下面的tomcat的使用要求了

5.tomcat的使用要求

使用tomcat的，要继承java的servlet包提供的HTTPserlet这个类，并重写doservice方法

6.这个技术的主要对象，api，属性 是什么，这几个主要对像之间的包含关系，一对一，一对多，多对多的关系

这很重要，也很有效：读代码和写代码也要紧盯对象和api和对象之间的关系，会让你写代码快，理解也快

其实idea可以看反编译的.class文件，想看什么对象，直接点进去看，其实比api文档方便，api文档看属性很麻烦，看源码可以直接看属性，类比前端，属性更重要，方法只是对属性的操作，当然不是完全正确的比喻，但是源码看属性，api看事件和插槽和数据看啥都行。。。。

可以分析出几个主要对象和对象的主要的api，和主要属性

7.对象一般都是包含关系，画个业务模型图就都有了

注意：这个一般叫架构，可以看架构概述，一般在写给开发人员的模块里找，是为了留口让你改源码用的，可以把jar翻译成代码，改一下想改的地方，编译之后再把jar包扔回去

这个结论是写前端的组件写出来的感觉

用在后端也没有错

业务模型上来说

对象之间的关系基本一对一，一对多，多对多，

一对一：对象的属性一个对象

一对多：对象的属性一个对象集合

要是哪天混了，就想一想封装组件时留的口，也就是props

组件里，props都是给方法或界面用的，或者给子组件，

Java里，这些定义的属性都是给对象的api用的，或者是给对象里的对象属性用的

8.为什么Server里的属性搜都搜不出来，标准实现类也搜不到，比如

1. • 在这个StandardServer类中，确实没有名为className的属性。从代码结构来看，这个类主要管理服务器相关的资源和操作。
   • 它包含了如globalNamingResources（用于管理命名资源）、port（服务器监听的端口号）、address（服务器监听的地址）、services（与服务器关联的服务数组）等属性。
2. 可能的原因
   • 功能定位 ：这个类的功能主要是围绕服务器的运行时状态、资源管理、生命周期等方面，不需要一个名为className的属性。例如，它通过port和address属性来确定服务器的监听位置，通过services来管理与服务器相关的服务。
   • 设计模式 ：从类的继承关系（extends LifecycleMBeanBase implements Server）来看，它遵循特定的设计模式，在这种模式下，没有必要引入className这样的属性。例如，它继承LifecycleMBeanBase来遵循生命周期管理的模式，实现Server接口来满足服务器相关的功能规范。

如果在其他地方有对className的需求，可能需要从外部传入或者通过其他相关类来管理，而不是在这个StandardServer类中直接定义。

9.主要对象的架构和代码上的联系

1.只new一个Tomcat对象，里面基本为空

2.根据架构，我们发现Connector和Tomcat对象中间有好几层

且我们看到tomcat基本为空

但tomcat.getConnector()我们仍然能获取到，看上图

这个在我之前理解，这是与架构不符的，应该在service里获取呀

但是打开上面的tomcat对象，发现tomcat对象的内容改变了，多了好多东西

发现得到的对象就是tomcat里的

这可太符合架构了。。。。

3.再看一下host呢

又被我猜到了，就是这个host，这个是Host的标准实现类

这个跟架构简直一摸一样

4.从tomcat对象上获取对象就只能到这了，这是tomact方法的极限了，但是根据架构,如果我们想用api去配servlet的路径和姓名，在次之前还要配Context的路径，但是不知道用哪个api呀，这个时候就去debugge的host的对象里看，看里面有什么

发现并不是很明显，但是我们要清楚我们在做的是让tomca能认识我们的

看一下官网的api，看不懂，但是通过架构猜，Context是在Host的孩子数组里，

那就找api吧，要看api是不是为两个对象建立了联系，一般就是把一个对象放到另一个对象里，一般从对象的api里判断

比如

host提供了对这个数组的增删改查，又和我们猜的架构（业务模型）差不多，

更重要的一点是Containner是所有容器组件的父类，

哈哈哈，被我懂完了

高兴太早了，居然空指针，好羞耻，

看一下，

应该是没有设置应用（上下文对象）的路径，深一层degugge看出来的

配一下，就好了

接下来配我们的url，也就是我们真正的资源定位

猜测应该在这两个属性上

servlet对象放孩子数组里，然后去配mapping映射

结果

根据上图，直接获取host会导致没有连接器的创建，根据架构，连接器是和engine平级的

手动加了连接器之后，还需要配连接器的监听端口，不然监听端口的默认值是-1

这是tomcat调用添加context的语句的源码，

这个才算进了servlet

其它的都差不多，就是为什么要加一个生命周期监听器呢

10.进了servlet之后响应（搞错了，别看）

6.在重写的方法里加东西，也就是响应回去，直接200

响应什么，什么就是页面源码，这就好办了，为什么这样说呢，忘了就去看一下xml那一部分，涉及到浏览器打开文件。。。。根据浏览器会个根据格式解析他认识的文件格式，所以现在尝试相应一个图片回去，因为文本格式的太简单了

1.静态资源响应：

1.在请求里请求静态资源，文件等

执行getRealPath操作之前，Tomcat的相关资源已经启动才行

String rootPath = context.getRealPath("/");

public class MyTomcatStart {
    public static void main(String[] args) throws LifecycleException {
        Tomcat tomcat = new Tomcat();
        Host host = tomcat.getHost();
        //连接器获取与配置
        Connector connector = new Connector();
        connector.setPort(8888);
        tomcat.setConnector(connector);
//        Context context = tomcat.addContext(host, "/myapp", "C://");
        //应用路径配置，
        Context context = new StandardContext();
        context.setPath("/myapp");
        //Web应用根目录的实际路径，指定静态资源的根目录
        context.setDocBase("D:/学习资料/图片");
        context.setName("/myapp");
        context.addLifecycleListener(new Tomcat.FixContextListener());
        host.addChild(context);
        //动态资源请求的servlet
        tomcat.addServlet(context, "myServlet", "org.example.servlet.MyServlet" );
        //静态资源请求的servlet ，把所有未被其他Servlet处理的请求映射到DefaultServlet，从而处理静态资源
        DefaultServlet defaultServlet = new DefaultServlet();
        tomcat.addServlet(context, "DefaultServlet", "org.apache.catalina.servlets.DefaultServlet" );
        context.addServletMappingDecoded("/myServlet", "myServlet");
        context.addServletMappingDecoded("/*", "DefaultServlet");
        tomcat.start();
        tomcat.getServer().await();

    }
}

http://localhost:8888/myapp/1_overview.png

有点难史，但是总的思路是

1.配置上下文的根目录，也就是告诉tomacat，请求myapp的静态资源，要到哪里找然后吐出去

2.将tomcat提供的处理静态资源请求的org.apache.catalina.servlets.DefaultServlet放到context的孩子数组

3.给处理静态资源请求的servlet配上请求的url

//静态资源请求的servlet ，把所有未被其他Servlet处理的请求映射到DefaultServlet，从而处理静态资源

4..先进到处理静态资源请求的servlet里，然后再调请求的文件路径

5.请求的静态资源的路径的处理，

没什么好处理的，反正很难调，记住就完了。。。

但是myapp后面的一部分，基本上就是请求的文件内容了，你只要加，就找不到，除非你的根目录那有相同的目录对应，

静态资源服务配置时，只要能进servlet，就直接在DefaultServlet源码里debuge去看要找的文件的路径是什么就好了，然在调，要么在你本地加目录，要么在浏览器台调url，没什么其它好办法。