|
|
昨天在家里整理我的宝贝硬盘时，发现之前的一个基于JSP结构的电子交易平台的源码，而且还有数据库，反正也没事，于是就想弄一下，让它跑起来。接下来，下载安装Tomcat和Sql Server的JDBC驱动（JDK之前就安装过），经过一系列的配置，通过测试JSP能够正常运行，JavaBean也能够正确运行，Servlet也能够正确运行，看样子环境应该没有问题。紧接着关键的部分就要来到了。我把Sql Server的JDBC驱动的三个JAR包放到了系统的classpath里，然后，启动Tomcat，并且迫不及待的在浏览器地址栏里输入http://localhost:80/IC/，静静地等待着系统的出现。系统终于跑起来了，可是看到的跟我的想象的不一样，界面上凡是有对数据库的访问的地方都出现了“This connection has not been established yet.”，很显然问题出在和数据库的连接上。
经过分析发现，系统对数据库的访问是透过一个JavaBean来实现的。于是，我把这个JavaBean的源码拷到了类似于记事本一样的文本编辑器里，并且加了main方法，来测试这个类是否工作正常。编译得到class文件后，用java xxx来执行，从输出来看，没有问题。但问题到底出在哪里呢？于是，我又把这段代码拷贝到Eclipse的一个工程里，编译执行后，报的错跟访问JSP的错是一样的，进一步跟踪发现，在Class.forName(“com.microsoft.jdbc.SQLServerDriver”);时报类没有找到，也就是说没有找到类SQLServerDriver，再打开mssqlserver.jar一看，类SQLServerDriver赫然在立，路径也没有错。我明明在classpath里加载了三个JAR包啊，为什么在命令行方式可以找到，在Eclipse里反倒没有找到呢？太让人困惑了！周末的好心情完全被这个问题搅乱了，并且暗暗下定决心，一定要解决而后快。接下来，就是上论坛问人，还有就是在QQ和MSN上找人问，同时，自己也在分析可能的原因，进行尝试。
联想到工作中经常把用到的JAR包都会加到项目的类路径中，于是，我也把三个JAR包添加到项目的类路径中，然后重新编译执行，发现问题没有了，输出正常。此时，我就初步断定问题出在Eclipse里执行类时加载的包跟系统的classpath指定的不一致，也就是说系统的classpath指定的类根本就没有加载到内存，所以就会报找不到类，而在命令行方式，加载的就是系统的classpath指定的包。问题虽然明确定位了，但具体是什么原因，我还是无法解释。结合在JSP里，我如何在启动Tomcat时先把三个jar包加载到内存呢？我写了个批处理文件，内容是set classpath=E:\xxxxx\msbase.jar;E:\ xxxxx\mssqlserver.jar;E:\ xxxxx\msutil.jar;我在命令行方式下，先执行这个批处理，然后，在执行启动Tomcat的命令，后来发现，依旧报错，说明这样加载jar包有问题。到这里，我几乎都想放弃了，想不到居然被这个classpath搞得焦头乱额，郁闷啊！但要我放弃，还真是不服气！还是休息一下，回头再来！
在客厅转了一下，弄了点东西吃了，感觉有点困，于是就睡去了。一觉睡了两个小时，起来的时候天色已暗，于是，又回到计算机旁，想想怎样才能搞定它！于是，在大脑里搜索工作中跟classpath有关的一些问题，以及解决方法。依稀记得，在Jdk的jre\lib\ext里的jar包，java是自己会自动加载的，于是，我又把三个jar包拷到这里，重新启动tomcat，在浏览器地址栏里输入访问地址，静静的等待以后，系统终于没有报之前的错误了，数据库连接正常了，终于跑起来了。我重重的舒了口长气，不容易啊。
到这里系统跑起来了，但classpath并没有彻底搞明白，我只是绕开了这个问题。今天一上班，我就想问南哥，但考虑到星期一上午大家都会比较忙，我忍住了。在中午快吃饭的时候，我还是问了这个问题。南哥的解释是，在命令行方式，java自己会加载系统的classpath里指定的包，而在Eclipse等开发环境里，系统加载的是开发环境的classpath。这个解释，跟我的实验情况完全吻合，听起来也没有问题。为了进一步确认在两种场景下classpath加载内容有什么不同，南哥建议我用System.getProperties()看看到底有什么差异？当我比较两种情况下的输出时，困扰了我一天的classpath问题，彻底弄明白了：通过命令行方式，来java xxxx时，会加载系统的classpath里的包，其方式是java.class.path=””，同时还会通过sun.boot.class.path=””的方式来加载jdk下的jre\lib\下的jar包，对于ext目下的包的加载，应该是通过java.ext.dirs=W:\jdk\jre\lib\ext来进行的，但这里没有具体的包名；通过IDE环境来执行java程序时，会加载环境指定的jar包。
编后：
在命令行方式下，通过我先执行加载环境的批处理，后启动Tomcat和直接启动Tomcat得到的两份系统属性,对比其中的java.class.path来看,两者完全一样,亦即在当前的使用场景下想通过批处理来加载jar包,是行不通的.进一步尝试,在单纯的命令行方式下通过批处理来加载jar包,然后执行java xxxx,跟踪系统属性得到的java.class.path跟批处理要求加载的完全一致.另一方面,在tomcat的webapp下建立自己的应用例如Test,然后在Test的WEB-INF目录下,建立目录lib,把你的jar包放到这里,也可以让tomcat找到你要加载的类.文中在前面提到,把jar放到jre\lib\ext\下系统能够运行,说明也没有问题,在tomcat的使用场景下,建议采用放到WEB-INF的lib目录下的方式.这样处理,很显然的一个好处是增强了系统的可移植性.
|
|
