1 tomcat 加载顺序
当我们启动一个tomcat的服务的时候,jar包和claess文件是是以怎么样的顺序被加载进来的?
加载顺序:
1. $java_home/lib目录下的java核心api
2. $java_home/lib/ext目录下的java扩展jar包
3. java-classpath/-Djava.class.path所指的目录下的类与jar包
4. $CATALINA_HOME/common目录下按照文件夹的顺序从上往下依次加载
5. $CATALINA_HOME/server目录下按照文件夹的顺序从上往下依次加载
6. $CATALINA_BASE/shared目录下按照文件夹的顺序从上往下依次加载
7. 我们的项目路径/WEB-INF/classes下的class文件
8. 我们的项目路径/WEB-INF/lib下的jar文件
在同一个文件夹下,jar包是按顺序从上到下依次加载
由ClassLoader的双亲委托模式加载机制我们可以知道,假设两个包名和类名完全相同的class文件不再同一个jar包,如果一个class文件已经被加载java虚拟机里了,那么后面的相同的class文件就不会被加载了。
2 tomcat 版本7和6的区别
今天开始在单位推广 Tomcat7 ,竟然碰到了好多问题。到现在才刚刚解决的差不多。在此介绍一下。
Tomcat6下边程序运行极其正常换了 Tomcat7 忽然不能用的都来看看了~
-------------------- ---------- ---------- ----------
第一个问题是关于数据库驱动程序加载。受数据库驱动异常困扰的同胞们,Tomcat7 下边因为 Tomcat 限定了类加载执行时静态代码的执行,需要在生成对象的时候才能够真正执行,所以在 Tomcat6 以前大家熟悉的数据库驱动程序加载方式:
[html] view plaincopyprint?
1. Class<?> cls = com.mysql.jdbc.Driver.class;
或者
[html] view plaincopyprint?
1. Class.forName("com.mysql.jdbc.Driver");
都已经不能用了。在使用 DriverManager 生成的数据库连接的时候,会出现“No suitable driverfound for jdbc”这个异常。
现在正确的数据库驱动程序加载方式,要求生成数据库驱动类的对象。推荐
[html] view plaincopyprint?
1. com.mysql.jdbc.Driver.class.newInstance();
这种方式不用处理异常,而且生成的无用对象会最短时间被垃圾回收。
当然了,也可以用一个引用类型变量把此对象接出来,但没有什么实际用途吧……
[html] view plaincopyprint?
1. java.sql.Driver driver = com.mysql.jdbc.Driver.class.newInstance();
其中 java.sql.Driver 是各个数据库管理系统提供的驱动程序类的接口,属于 JDBC 规范,适合用 import java.sql.Driver; 进行缩写。
-------------------- ---------- ---------- ----------
第二个问题,是线程启动的问题。因为 Tomcat7 或者 -server 方式运行的爪哇虚拟机(JVM)的一些我尚未掌握的保护机制,所以当一个线程经历空循环时,就会被架空。
[html] view plaincopyprint?
1. while(flag) { }
于是通过 flag 作为线程控制变量的控制方法,就没办法继续使用了。这个时候,要时常跳过这个人工卡死的线程,以便其能够总在执行而不会真的陷入僵死。
[html] view plaincopyprint?
1. while(flag) { Thread.yield(); }
-------------------- ---------- ---------- ----------
Tomcat7 的配置文件中,Context 配置,debug 属性被取消了,如果依然使用,会报出一个警告。
同时 unpackWAR 属性的默认值,在 Tomcat6 时是 true ,意味着默认状态将会解压 .war 然后再执行;而 Tomcat7 变成了默认 false ,不展开。
-------------------- ---------- ---------- ----------
另外还有一个并不是 Tomcat7 新有的特点。之前conf/Catalina/localhost 下边会自动建立 ROOT.xml ,现在不会了。然后之前此目录下的配置文件,会以其中 path 属性指明的路径为“应用路径”;现在则会以 XML 文件的名字作为应用路径。如果大家想制作一个不需要填写应用路径就可以访问的应用,请记得一定要自己建立一个 ROOT.xml ,区分大小写,然后在其中编写 <Context> 片段。
[html] view plaincopyprint?
1. <Context
2. crossContext="true"
3. privileged="true"
4. path=""
5. docBase="/usr/local/example.war"
6. reloadable="false"
7. unpackWAR="true"
8. cachingAllowed="true"
9. cacheMaxSize="1024"
10. ></Context>
这个例子比较全。其中
crossContext="true" ,是允许应用通过 ServletContext.getContext() 去拿到一个通往别的应用 request dispatcher 。当然了,这种方法无法跨越现在 Tomcat 支持的虚拟主机界限。也就是说,能够穿透访问的,必须是和当前应用在一个 <Host> 之中的应用。
privileged="true" 意味着 Tomcat 自身的应用,比如· Tomcat Manager,可以被当前这个应用访问。根据官方文档的解释,这个机理是改变应用的类加载器为 Server classloader 。我想,这种改变,会令应用程序发现 Tomcat 本身的类,都能够从应用自己的类加载器上寻找到。从而实现对 Tomcat 自身应用程序方法的调用。
path 和 docBase 不用多说,都要指定这二个属性的。其中 docBase 可以是目录也可以是结构完整的 .war 文件。
reloadable="true" 意味着 Tomcat 将提供对应用类路径(/WEB-INF/classes/ 和 /WEB-INF/lib/ )的监测。当这里边有内容改变并且其类已经被爪哇虚拟机(JVM)加载的时候,Tomcat 可以自行重新加载此类。不过此功能对 Tomcat 的稳定服务影响不小,调试环境可以使用,生产环境还是算了吧——当然,这只是我的个人建议。
unpackWAR 就如字面意思,unpackWAR="true" 意味着 Tomcat 会保存 .war 包的解压结果,然后直接对解压结果进行运行。我个人认为,考虑到爪哇虚拟机的类加载机制,每个类都仅加载一回,但是页面内容却没有类似的有效缓存,所以 .war 还是解压执行的比较好。而且日志也将造成 unpackWAR="false" 形同灾难。
cachingAllowed="true" 意味着开启了 Tomcat7 的静态缓存功能。静态文件包括 JavaScript 程序、图片声音等允许网络访问的文件以及 HTML 页面。
cacheMaxSize 是静态缓存功能缓冲区大小的设定。单位是 MB ,也就是 1024KB 。例子中设为 1024 ,意味着 1GB 。
3 jdk7/6区别
首先是模块化特性:现在的 Java7也是采用了模块的划分方式来提速,一些不是必须的模块并没有下载和安装,因此在使用全新的Java7的虚拟机的时候会发现真的很快,当虚拟机需要用到某些功能的时候,再下载和启用相应的模块,这样使得最初需要下载的虚拟机大小得到了有效的控制。同时对启动速度也有了很大的改善。如果你对 OpenJDK的架构比较熟悉,你甚至可以定制JDK的模块。
其次是多语言支持:这里的多语言不是指中文英文之类的语言,而是说Java7的虚拟机对多种动态程序语言增加了支持,比如:Rubby、 Python等等。对这些动态语言的支持极大地扩展了Java虚拟机的能力。对于那些熟悉这些动态语言的程序员而言,在使用Java虚拟机的过程中同样可以使用它们熟悉的语言进行功能的编写,而这些语言是跑在功能强大的JVM之上的。
再有是开发者的开发效率得到了改善:Java7通过多种特性来增强开发效率。比如对语言本身做了一些细小的改变来简化程序的编写,在多线程并发与控制方面:轻量级的分离与合并框架,一个支持并发访问的HashMap等等。通过注解增强程序的静态检查。提供了一些新的API用于文件系统的访问、异步的输入输出操作、Socket通道的配置与绑定、多点数据包的传送等等。
最后是执行效率的提高,也是给人感觉最真切体验的特性:压缩了64位的对象指针,Java7通过对对象指针由 64位压缩到与32位指针相匹配的技术使得内存和内存带块的消耗得到了很大的降低因而提高了执行效率。此外还提供了新的垃圾回收机制(G1)来降低垃圾回收的负载和增强垃圾回收的效果。G1垃圾回收机制拥有更低的暂停率和更好的可预测性。
4 hibernate 事务
5 jquery选择器
jQuery 元素选择器
jQuery 使用 CSS 选择器来选取 HTML 元素。
$("p") 选取 <p> 元素。
$("p.intro") 选取所有 class="intro"的 <p> 元素。
$("p#demo") 选取 id="demo" 的第一个 <p> 元素。
jQuery 属性选择器
jQuery 使用 XPath 表达式来选择带有给定属性的元素。
$("[href]") 选取所有带有 href 属性的元素。
$("[href='#']") 选取所有带有 href 值等于 "#" 的元素。
$("[href!='#']") 选取所有带有 href 值不等于 "#" 的元素。
$("[href$='.jpg']") 选取所有 href 值以 ".jpg" 结尾的元素。
jQuery CSS 选择器
jQuery CSS 选择器可用于改变 HTML 元素的 CSS 属性。
$("p").css("background-color","red");
6 jquery/extjs的核心
jQuery是为了改变javascript的编码方式而设计的
7 hibernate方言
Hibernate底层依然使用SQL语句来执行数据库操作,虽然所有关系型数据库都支持使用标准SQL语句,但所有数据库都对标准SQL进行了一些扩展,所以在语法细节上存在一些差异,因此Hibernate需要根据数据库来识别这些差异。
举例来说,我们在MySQL数据库里进行分页查询,只需使用limit关键字就可以了;而标准SQL并不支持limit关键字,例如Oracle则需要使用行内视图的方式来进行分页。同样的应用程序,当我们在不同数据库之间迁移时,底层数据库的访问细节会发生改变,而Hibernate也为这种改变做好了准备,现在我们需要做的是:告诉Hibernate应用程序的底层即将使用哪种数据库——这就是数据库方言。
一旦我们为Hibernate设置了合适的数据库方言,Hibernate将可以自动应付底层数据库访问所存在的细节差异。
不同数据库所应使用的方言如表5.1所示。
表 不同数据库及其对应方言
关系数据库 | 方 言 |
DB2 | org.hibernate.dialect.DB2Dialect |
DB2 AS/400 | org.hibernate.dialect.DB2400Dialect |
DB2 OS390 | org.hibernate.dialect.DB2390Dialect |
PostgreSQL | org.hibernate.dialect.PostgreSQLDialect |
MySQL | org.hibernate.dialect.MySQLDialect |
MySQL with InnoDB | org.hibernate.dialect.MySQLInnoDBDialect |
MySQL with MyISAM | org.hibernate.dialect.MySQLMyISAMDialect |
Oracle(any version) | org.hibernate.dialect.OracleDialect |
Oracle 9i | org.hibernate.dialect.Oracle9iDialect |
Oracle 10g | org.hibernate.dialect.Oracle10gDialect |
org.hibernate.dialect.SybaseDialect | |
Sybase Anywhere | org.hibernate.dialect.SybaseAnywhereDialect |
Microsoft SQL Server | org.hibernate.dialect.SQLServerDialect |
SAP DB | org.hibernate.dialect.SAPDBDialect |
Informix | org.hibernate.dialect.InformixDialect |
HypersonicSQL | org.hibernate.dialect.HSQLDialect |
Ingres | org.hibernate.dialect.IngresDialect |
Progress | org.hibernate.dialect.ProgressDialect |
Mckoi SQL | org.hibernate.dialect.MckoiDialect |
Interbase | org.hibernate.dialect.InterbaseDialect |
Pointbase | org.hibernate.dialect.PointbaseDialect |
FrontBase | org.hibernate.dialect.FrontbaseDialect |
Firebird | org.hibernate.dialect.FirebirdDialect |
如果一个系统可能运行于多种数据库,或者同时使用多种数据库,那么,使用Hibernate将会给你带来很多的方便,想信很多接触Hibernate的人都会体会到。Hibernate底层是通过dialect包来对各种数据库的差异进行抽象的。Dialect类中实现每种数据库相同的东西,而不同数据库对应会有该类的一个扩展实现,最终通过DialectFactory来决定创建哪一个类。通常我们都会指定hibernate.dialect属性,那直接创建该属性对应的类。如果我们没有指定该属性,那么由Hibernate自己决定选择合适的方言。在DialectFactory中初始化各种数据库对应的方言的Map,以数据库产品名为key,以方言的包装对象为value。Hibernate自动选择方言时,会通过JDBC的DatabaseMetadata取得数据库的产品名称,根据名称取得对应的方言。DialectFactory中对该Map的初始化的部分代码如下:
- // TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place
- private static final Map MAPPERS = new HashMap();
- static {
- // detectors...
- MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) );
- MAPPERS.put( "H2", new VersionInsensitiveMapper( "org.hibernate.dialect.H2Dialect" ) );
- MAPPERS.put( "MySQL", new VersionInsensitiveMapper( "org.hibernate.dialect.MySQLDialect" ) );
- MAPPERS.put( "PostgreSQL", new VersionInsensitiveMapper( "org.hibernate.dialect.PostgreSQLDialect" ) );
- MAPPERS.put( "Apache Derby", new VersionInsensitiveMapper( "org.hibernate.dialect.DerbyDialect" ) );
- <SPAN>...</SPAN> 原本上,这种自动选择的方式,会给我们带来方便,只可惜,从以上的代码的注释中可以知道,目前这一部分的初始化是通过硬编码的,只有在以后的版本才会移动到配置文件或其他容易用户编译的地方,否则,我们可以非常容易的添加我们的配置供Hibernate进行自动选择。而经常我们所使用的数据库驱动程序所取到的数据库产品名称会跟以上硬编码的不同,所以最终我们还是得自己配置数据库方言。
由于我们的系统中用到了好几个数据源,经常也是对应不同类型的数据库,并且数据源都是由容器提供的,在首次部署时经常因为数据库类型变了而忘了修改对应的数据库方言,而出了问题,这给实施人员带来了很多的不便。不过目前除了对各种数据库提供与以上硬编码相同的数据库产品名称的驱动程序外,我们就只能自己动手了
8 闭包实例
9 原型实例
10 tomcat目录结构
首先来了解一下Tomcat5.5的目录结构:
/bin:存放windows或Linux平台上启动和关闭Tomcat的脚本文件
/conf:存放Tomcat服务器的各种全局配置文件,其中包括server.xml(Tomcat的主要配置文件)、tomcat-users.xml和web.xml等配置文件
/server/lib:存放Tomcat服务器所需的各种JAR文件(但是不能被web应用访问)
/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:Tomcat将JSP生成的Servlet源文件和字节码文件放到这个目录下
/temp:存放Tomcat运行时所产生的临时文件
而Tomcat6.0的目录结构则比5.5简化了很多 目录如下:
/bin:存放windows或Linux平台上启动和关闭Tomcat的脚本文件
/conf:存放Tomcat服务器的各种全局配置文件,其中包括server.xml(Tomcat的主要配置文件)、tomcat-users.xml和web.xml等配置文件
/lib:存放所需的所有jar文件(整合了原来tomcat5.5中的common/share/server三个目录下的所有jar)
/logs:存放Tomcat执行时的日志文件
/temp:存放Tomcat运行时所产生的临时文件
/webapps:Tomcat的主要Web发布目录,默认情况下把Web应用文件放于此目录(原/server/webapps下的manager等应用也已转移至此)
/work:Tomcat将JSP生成的Servlet源文件和字节码文件放到这个目录下
Tomcat6.x与5.x在目录上最大的区别就是将所有的lib包直接置于 CATALINA_HOME/lib目录下
11 开启多个tomcat
11.1回答一:
前些时日,出于某种需要,需要同时启动多个Tomcat服务器,在网上查了半天,才找到解决的办法,拿出来分享一下,嘿嘿。
我所用Tomcat服务器都为zip版,非安装版。以两个为例:
安装第二个Tomcat完成后,到安装目录下的conf子目录中打开server.xml文件,查找以下三处:
(1) 修改http访问端口(默认为8080端口)
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080"
minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="100" debug="0" connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
(大概在86行左右)将8080修改为第一个tomcat不在使用的端口号。此处所设的端口号即是以后访问web时所用的端口号。
(2) 修改Shutdown端口(默认为8005端口)
<Server port="8005" shutdown="SHUTDOWN" debug="0">
(大概在13行左右)将8005修改为没有在使用的端口号,例如8095
(3) 修改JVM启动端口(默认为8009端口)
< Connector className ="org.apache.coyote.tomcat4.CoyoteConnector"
port ="8009" minProcessors ="5" maxProcessors="75"
enableLookups ="true" redirectPort ="8443"
acceptCount ="10" debug ="0" connectionTimeout="20000"
useURIValidationHack ="false"
protocolHandlerClassName ="org.apache.jk.server.JkCoyoteHandler" />
(大概在107行左右)将8009修改为没有在使用的端口号,例如8099
这样就没问题了。
11.2 方案2
删除环境变量中的CATALINA_HOME和CATALINA_BASE (关键)
比如我想同是启动N个tomcat
复制N个tomcat源文件包(当然如果在同一文件夹下需要手动重命名一下)
分别修改安装目录下的conf子目录中的server.xml文件:
a.修改http访问端口(默认为8080端口),将8080修改为tomcat唯一的,其他tomcat不在使用的端口号。此处所设的端口号即是以后访问web时所用的端口号。
b.修改Shutdown端口(默 认为8005端口),将8005修改为唯一的的端口号,例如8055。
c.修改8009端口,将8009修改为没有在使用的端口号,例如8099(注 意:N个文件中对应的端口号要都不一样)
依次启动N个tomcat。 答:对就是改server.xml把共用的端口分开就行了
另外,
若用MyEclipse来启动Tomcat的话,那么配置Tomcat的版本必须不一样才能同时配置上去,比如,同时配置四个Tomcat6是不可能的,但是Tomcat4,5,6,7是可以同时配置的!