web容器

Servlet规范定义的类加载顺序 在Servlet规范中有对web应用程序类的加载方式作出建议，重要的有两点： 容器要加载某个类时，类加载器首先应该加载本地web应用程序中“WEB-INF/classes”路径中的类，然后再到“WEB-INF/lib”依赖库中加载类，最后在容器级别的lib中加载类； 同时，类加载器要保证应用程序不会覆盖Java核心类，即 java.* 和 javax.* 命名空间中的类，也就是说web应用程序如果定义了一个和java核心类名字相同的类则是无效的。 Tomcat的应用程序类加载器 Tomcat内部有多种类型的类加载器，其中 WebappClassLoader 是应用程序类加载器，tomcat启动时对于它管理的每个web应用程序都会创建一个单独 WebappClassLoader 实例，在tomcat内部的 StandardContex 类中的启动方法中找到。 根据servlet规范，容器要首先在本地应用程序库中加载请求的类，同时要避免应用程序中的类覆盖Java平台类库中的核心类， WebappClassLoader 加载器为了实现这些要求没有遵循java的父加载器委托的模型，它重写了ClassLoader的 loadClass 方法，重写的 loadClass 方法的源代码细节如下： // 代码省略了一些与类加载逻辑关系不大的细节

在 关于类加载器 中已经介绍了Jvm的类加载机制，然而对于运行在Java EE容器中的Web应用来说，类加载器的实现方式与一般的Java应用有所不同。不同的Web容器的实现方式也会有所不同。 Tomcat中的类加载机制 在Apache Tomcat 中，为了提高系统的灵活性，引入了commonLoader、sharedLoader、catalinaLoader；为了支持和分隔多个web应用，使用了WebappClassLoader。下面以Tomcat7.0的类加载器结构图总体来看大致如下： Bootstrap | System | Common / \ Webapp1 Webapp2 ... Tomcat中的系统类加载器。Tomcat也是一个Java应用，他也是在最初系统提供的几层类加载器环境下运行起来的。那么Tomcat的一些最基本的类，也和其它简单Java应用一样，是通过系统的类加载器来加载的，比如默认配置下的tomcat/bin目录下的bootstrap.jar、tomcat-juli.jar、commons-daemon.jar这几个jar包中的类。 Tomcat的Common Loader。Common Loader是Tomcat在系统类加载器之上建立起来的，其父loader是系统类加载器。Common Loader负责上面几个jar包外的Tomcat的大部分java类

服务器环境是 RedHat Linux, 其上运行的是 Apache + Tomcat，容器中运行的是我们公司的壹个小型电子商务网站，原来项目里的日志信息都是直接随着 Tomcat 容器壹起打印到 /tomcat/logs/catalina.out 中，与服务器本身的日志混合在壹起，特别难看，尤其当日志信息很多时，总是把重要的信息给冲掉了。感觉特别不爽。于是从两个月前开始，我就想把这个问题给解决下，思路就是给应用程序单独配置日志的输出方式，将其重定向到指定的日志文件，这样，我们可以简单的通过查看日志文件的方式来了解代码运行过程中可能存在的问题。 应用程序原来使用的是 LOG4J 来打印日志信息，查了下相关资料，最后我决定选用 Rolling File Appender，因为这种方式打印日志，当日志容量达到指定值时，如100MB，会自动重新生成壹个新的文件，并把原来的100MB 文件备份，这样，就可以将某一段时间内的日志信息都保留在服务器上，对于服务器维护很有帮助。 项目中的 log4j.properties 配置信息如下： log4j.rootLogger=DEBUG, ROLLING_FILE log4j.additivity.org.apache=true log4j.appender.ROLLING_FILE=org.apache.log4j

基于 Java 的Web 应用程序是 servlet、JSP 页面、静态页面、类和其他资源的集合，它们可以用标准方式打包，并运行在来自多个供应商的多个容器。Web 应用程序存在于结构化层次结构的目录中，该层次结构是由 Java Servlet 规范定义的。Web 应用程序的根目录包含直接存储或存储在子文件夹中的所有公共资源，比如图像、HTML 页面等。构成：Web应用由Web组件(一组Java类库)、html文件，静态资源文件（如图像）、帮助类和库组成。 Tomcat 服务器是一个免费的开放源代码的Web 应用服务器。 Tomcat 是一个小型的轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展，但它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。 这里的诀窍是，当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行JSP 页面和Servlet。另外，Tomcat和IIS、Apache等Web服务器一样，具有处理HTML页面的功能，另外它还是一个Servlet和JSP容器

基于 Java 的Web 应用程序是 servlet、JSP 页面、静态页面、类和其他资源的集合，它们可以用标准方式打包，并运行在来自多个供应商的多个容器。Web 应用程序存在于结构化层次结构的目录中，该层次结构是由 Java Servlet 规范定义的。Web 应用程序的根目录包含直接存储或存储在子文件夹中的所有公共资源，比如图像、HTML 页面等。构成：Web应用由Web组件(一组Java类库)、html文件，静态资源文件（如图像）、帮助类和库组成。 1 – Tomcat Server的组成部分 1.1 – Server A Server element represents the entire Catalina servlet container. (Singleton) 1.2 – Service A Service element represents the combination of one or more Connector components that share a single Engine Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求 1.3 – Connector 一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理

TOMCAT的目录结构 /bin：存放windows或Linux平台上启动和关闭Tomcat的脚本文件 /conf：存放Tomcat服务器的各种全局配置文件，其中最重要的是server.xml和web.xml /doc：存放Tomcat文档 /server：包含三个子目录：classes、lib和webapps /server/lib：存放Tomcat服务器所需的各种JAR文件 /server/webapps：存放Tomcat自带的两个WEB应用admin应用和 manager应用 /common/lib：存放Tomcat服务器以及所有web应用都可以访问的jar文件 /shared/lib：存放所有web应用都可以访问的jar文件（但是不能被Tomcat服务器访问） /logs：存放Tomcat执行时的日志文件 /src：存放Tomcat的源代码 /webapps：Tomcat的主要Web发布目录，默认情况下把Web应用文件放于此目录 /work：存放JSP编译后产生的class文件 WEB应用的目录结构： 假设在$CATALINA_HOME/webapps下有helloapp的web应用 /helloapp：Web应用的根目录，所有的jsp文件和html文件都在此目录下 /helloapp/WEB_INF：存放该web应用发布时的描述文件web.xml /helloapp

404错误产生原因及解决方法 在刚开始进行Web应用开发的时候，经常看见页面出现404这个数字，我们一般会称之为运行产生了404错误。类似于404这个数字，还有可能在页面上看到405、500这两个数字，他们都是服务器执行完客户端的请求以后，返回给客户端的一个关于执行结果的状态编码说明。 如果在运行结果页面中没有看到期待的页面，却看到了404、405、500这样的数字，那么代表着服务器告诉客户端运行产生了错误，掌握何种错误情况产生对应的数字将有利于问题的解决。 404产生的原因为Web服务器（容器）根据请求地址找不到对应资源，以下情况都会出现404的错误提示： 输入的地址有误（应用名大小写不正确，名称拼写不正确） 在web.xml文件中和中的两个不一致 没有将工程部署到Tomcat的webapps下面 Web工程部署时的结构没有遵循Servlet的规范 具体的解决办法就是根据上面提到的4种情况，逐条进行检查。 容器如何找到service（）方法 当在浏览器中输入 http://localhost:8080/firstweb/sayHi 这个地址后，容器是如何找到 HelloServlet.class这个文件并执行的呢？ 首先容器会根据firstweb这个应用名找到位于webapps下面对应的文件夹，然后根据地址中的“/sayHi”到web.xml文件中寻找与之匹配的节点

404错误产生原因及解决方法 在刚开始进行Web应用开发的时候，经常看见页面出现404这个数字，我们一般会称之为运行产生了404错误。类似于404这个数字，还有可能在页面上看到405、500这两个数字，他们都是服务器执行完客户端的请求以后，返回给客户端的一个关于执行结果的状态编码说明。 如果在运行结果页面中没有看到期待的页面，却看到了404、405、500这样的数字，那么代表着服务器告诉客户端运行产生了错误，掌握何种错误情况产生对应的数字将有利于问题的解决。 404产生的原因为Web服务器（容器）根据请求地址找不到对应资源，以下情况都会出现404的错误提示： 输入的地址有误（应用名大小写不正确，名称拼写不正确） 在web.xml文件中和中的两个不一致 没有将工程部署到Tomcat的webapps下面 Web工程部署时的结构没有遵循Servlet的规范 具体的解决办法就是根据上面提到的4种情况，逐条进行检查。 容器如何找到service（）方法 当在浏览器中输入 http://localhost:8080/firstweb/sayHi 这个地址后，容器是如何找到 HelloServlet.class这个文件并执行的呢？ 首先容器会根据firstweb这个应用名找到位于webapps下面对应的文件夹，然后根据地址中的“/sayHi”到web.xml文件中寻找与之匹配的节点

首先我们来看看容器如何找到service（）方法？ （1）当在浏览器中输入 http://localhost:8080/firstweb/sayHi 这个地址后，容器是如何找到 HelloServlet.class这个文件并执行的呢？ （2）首先容器会根据firstweb这个应用名找到位于webapps下面对应的文件夹， （3）然后根据地址中的“/sayHi”到web.xml文件中寻找与之匹配的<url-pattern>节点，找到匹配的节点后会找到与该节点紧邻的<servlet-name>节点，获取名称并在此寻找与该名称相等的<servlet-name>节点，找到相等的节点后，搜寻该节点下面紧邻的<servlet-class>节点，于是获取到了与该地址相对应的类名，借助于ClassLoader加载该类文件，创建对象并调用service（）方法，客户端即看到了与该地址匹配的运行结果。 一、404错误产生原因及解决方法 在刚开始进行Web应用开发的时候，经常看见页面出现404这个数字，我们一般会称之为运行产生了404错误。类似于404这个数字，还有可能在页面上看到405、500这两个数字，他们都是服务器执行完客户端的请求以后，返回给客户端的一个关于执行结果的状态编码说明。 如果在运行结果页面中没有看到期待的页面，却看到了404、405、500这样的数字

Java作为学习编程开发入门语言，可能对于许多新手来说可能有点摸不着北，做位一名有几年开发经验的老鸟，希望给一些新人分享经验，当然其他老鸟如果有什么意见可以指出，我也会努力纠正。 本人工作是有关Java Web 开发，所以我会以Java Web标准开发去做一个标准，当然Java 能做的事情很多,包括Android,Java Me等，后期只要我们努力可以学习更多，更深的我也说不了，我现在只谈谈怎么去入门，至于登堂入室，大家有了套路以后，都能够达到。我写这个初衷，是因为我本来是一名非计算机专业的学生，后来我渐渐地走向这条编程不归路时，深谙非本专业同学自学不易，所以我总结一些经验，希望能给学习Java的同学们一些帮助。 以下是一张总图。 我把Java Web学习分成6个阶段，本人也未完成所有的目标，毕竟学无止境嘛，而且编程本来就是不断学习，积累的过程。好了，我再详细的介绍每一个阶段的小目标，毕竟学习是一个循序渐进的过程。 第一个阶段，HTML,JavaScript,Css,这三个是网页展示的三个密切相连的技术。学习Html 需要从最基本的标签入手，学习Css需要从选择器,属性开始。至于JavaScript，就是要从Dom对象入手，以及理解,函数定义，监听事件处理。 Jquery是对JavaScript的一种简化,它有许多选择器,操作Dom对象，ajax请求，动画对象。 第二阶段,Java