关于classpath的设置

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/ecaol/article/details/385472


1.  直接设置

     在环境变量里面添加:
                                           java_home=C:/jdk130 (安装路径)
                                           classpath=.;C:/jdk13/lib/tools.jar;C:/jdk13/lib/dt.jar;C:/jdk13/bin; 
                                           path= C:/jdk13/bin;
2. 写在.bat文件中

     将要加载的jar文件添加到.bat文件中,在要编译的时候打开cmd,在cmd中运行一下.bat文件即可。
     当关闭cmd的时候,加载的库文件失效,下次进入需要重新加载。

                    set CATALINA_HOME=E:/Tomcat 4.1
                    set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%/common/lib/servlet.jar
                    set CLASSPATH=%CLASSPATH%;%CATALINA_HOME%/common/lib/tools.jar

3. 这种方法还没掌握

@Echo Off
Rem SetAll.bat
For %%i In ("%HIBERNATE_HOME%/lib/*.jar") Do Call "SetClassPath.bat" %%i
Set ClassPath


==============================================


@Echo Off
Rem SetClassPath.bat:

Set NewFile=%1
:Check
If %2a==a Goto SetValue
Shift
Set NewFile=%NewFile% %1
Goto Check
:SetValue
Set ClassPath=%CLASSPATH%;%NewFile%

展开阅读全文

关于设置CLASSPATH的问题,急!!

07-27

我安装了SQL SERVER 2000的JDBC驱动,安装目录为C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC,在该目录中有个lib文件夹,里面有三个.jar文件;rn然后我在环境变量中如此设置:d:\j2sdk1.4.2_0\lib\tools.jar;d:\jdk1.3.1_08\lib\dt.jar;C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\msbase.jar;C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\mssqlserver.jar;C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\msutil.jarrn我用的Web服务器是Tomcat5.0,在一个JSP页中链接数据库,运行时出错,说找不到com.microsoft.jdbc.sqlserver.SQLServerDriver,也就是我装的驱动,我怀疑是环境变量设的问题,然后我看了其他环境变量的设置,有的在分号后加.,然后我将CLASSPATH改为:d:\j2sdk1.4.2_03\lib\tools.jar;.d:\jdk1.3.1_08\lib\dt.jar;.C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\msbase.jar;.C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\mssqlserver.jar;.C:\Program Files\Microsoft SQL Server 2000 Driver for JDBC\lib\msutil.jarrn还出同样的错误,我不知道是怎么回事。rn在装JDBC驱动前,我的CLASSPATH是:rnd:\j2sdk1.4.2_0\lib\tools.jar;d:\jdk1.3.1_08\lib\dt.jarrn我编了一个HelloWorld的程序,可以成功编译,然后运行总显示rnException in thread "main" java.lang.NoClassDefFoundError:HelloWorldrn需要说明的是,以上的链接数据库的程序和HelloWorld都没有问题,我把JDBC驱动的lib夹里的.jar文件到我的网站的Web-INF的lib文件夹内,程序就可以正确执行,rn用JCreator编译执行HelloWorld也没有问题,rn所以我怀疑是我的CLASSPATH写的有问题,如果是这样应该怎么写??rnrnrn 论坛

(技巧提示)CLASSPATH 设置终结遍[classpath]

03-16

http://www.meangene.com/java/classpath.htmlrnrnThe documentation that comes with Software usually sucks. Servlet Engines are no exception. I get really mad when I have to spend an hour ( or six ) learning how to install some software just so I can get on with my work. Since I don't want you to suffer what I suffered ( and I don't want to suffer again if I forget ... ) Here is my guide to classpaths for two major servlet engines, JavaWebServer and JRun. rnrnThe basics rnThere are three places you set CLASSPATH information in JRUN and JWS. rnrnBy default the JRUN_HOME and JWS_HOME ( henceforth HOME ) directory has two subdirectories of interest for CLASSPATH issues. The HOME/servlets directory and the HOME/classes directory. Each also provides a way of setting a general CLASSPATH. rnHOME/servlets and dynamic class reloading rnThe /servlets directory is where you put your servlets during development and deployment. It is nice for development because the servlets in this directory will dynamically reload if they are changed. "Dynamically reload" means that you don't have to stop the web server in order to reload this class into the JVM that your servlet engine is using. rnIf you want to do dynamic class reloading ( you probably do ) DO NOT put HOME/servlets in your USER_CLASSPATH !!! rnrnThere is some subtlety to this system. The determination of "has a Servlet changed" is based solely on the date of the .class file of the servlet. It is _not_ based on the date of the supporting class files. For example, if you have a servlet Foo, and it instantiates an object of class Bar, the servlet Foo will dynamically reload if the Foo.class file has changed ( and if the Foo.class is in the /servlets directory ) If the Bar.class file has changed the Foo servlet will not dynamically reload. rnrnSince it is very common to have many classes supporting a servlet class, you can force a reload of your servlet's supporting classes ( if the supporting classes are also in the servlets directory ) by simply doing a "touch" on the servlet class file. Touch is a UNIX command that simply changes the date of a file to the current date without altering the file. I tested an example where my servlet was called Foo. The Foo servlet made an object of class Bar. Bar contained an object of class Baz. I modified Baz and reran my servlet. Nothing changed. I touched the Foo.class file and reran my servlet. I saw the change. rnrnIf you are on a lesser platform, like WindowsNT, I'm not sure how you can do a "touch". You could just recompile your servlet class, or you could get the gnuwin32 tool set free from cygnus which gives your NT platform the basic set of UNIX commands like touch. rnrnThough this worked in my simple test with JRun I'm not sure if it will always work. Some input from the various servlet engine makers would be appreciated here. I can say that I did another test where I deleted Baz.class and then touched Foo.class and reran the Foo servlet. The Foo servlet ran fine, even though Baz.class no longer existed. So perhaps it tried to reload Baz, and when it failed, it used the copy it already had. rnrnAnd this news, which I believe refers to the "touch" technique, from Spike Washburn at IBM. "This mechanism for reloading classes used by a servlet will work on ServletExpress as well." rnrnrnAnother alternative is to put all of your supporting files, along with your servlet, in a .jar file. This is pretty inefficient, but if the jar file changes ( because any of your classes have changed) the entire jar file should reload. If the "touch" technique works, I'd go with it way before this. Note, I've never tried this. rnrnHOME/classes - static ( not dynamic ) reloading rnIf you don't do anything about setting your CLASSPATH, the CLASSPATH used by either servlet engine will still contain HOME/classes. So if nothing else, its a default directory that will always be in the engine's CLASSPATH. rnClasses put in here will not dynamically reload. This means, if you change something in here, you must stop the Servlet Engine, which may mean stopping the web server ( certainly for JWS ) and restarting it. rnrnTechnically, you need only stop the Virtual Machine that the Servlet Engine is using. JRun allows for multiple virtual machines, so I'm not sure how you force a reload into all of them without stopping the server. That would be an advanced technique and some commentary from LiveSoftware would be appreciated here. rnrnYou should be able to put .jar files or whaterver you want in the HOME/classes directory, though I've never tried. rnrnThis from Alfred Werner at Thunderstruck .... ( speaking about JWS ) rnrnIf you create a servlet, e.g com.thunderstick.fooHandlerServlet, and your CLASSPATH points to the servlets directory, it doesn't look in $SERVER_ROOT/servlets/com/thunderstick but rather in $SERVER_ROOT/servlets for fooHandlerServlet. This to me is wrong, but empirically speaking that's the way it is. rnOn the other hand, if I decide to use PropertyResourceBundles, that is, fooHandlerServlet.properties, JWS will indeed look in $SERVER_ROOT/servlets/com/thunderstick/ . Go figure. rnrnUSER_CLASSPATH ( or the User's CLASSPATH ) rnIn JRun, you can set the USER_CLASSPATH directive in your web server. The installation instructions should say how to do this. For Apache, you add a line like this to your srm.conf file. rnJRunConfig USER_CLASSPATH /home/foo/:/home/bar/:/usr/local/jdk/lib/: rnrnAs the manual's Apache Notes says: rnrn Note that these must be present in the main server configuration; rn any of the following directives placed in a virtual server config rn will be ignored:rn rnA virtual server config refers to additional "virtual" domain or host names that you may have configured your web server to answer to. rnrnFor Netscape, it looks like you add a line like this to your obj.conf file: rnrnrn Init classpath="d:/program files/livesoftware/jrunisapi/lib/jrun.jar;"rn rnJavaWebServer should pick up your CLASSPATH environment variable. Remember that your web server ( and hence your servlet engine ) will probably not run under your user account. Generally they run under the root account, or a special user account. Make sure that that user account has the CLASSPATH you want. Alternately, you can specify in a shell program that launches the server, what the CLASSPATH is. How you do this depends on your shell. If you use tcsh, you say something like this. rnrnrnrn setenv CLASSPATH "/home/foo/: ... "rn rnif you use bash you say something like this. rn set CLASSPATH="/home/foo/: ... "rn export CLASSPATH rn rnIf you use WindowsNT, set the System classpath in the System Control Panel under the environment tab. rnrnThe Servlet's CLASSPATH rnSo your servlet engine will always look in HOME/servlets, and HOME/classes and your USER_CLASSPATH. To this, JRun will add a few directories of its own, whether you specified them in your USER_CLASSPATH or not. If you want to see the entire CLASSPATH used by your servlet engine, take a working servlet and add these lines. Note that the old Java System call getenv has been deprecated. Use getProperty instead. rnrn try classPath = System.getProperty( "java.class.path" ) ; rn catch ( Exception e ) rn rn System.out.println( "Exception: " + e ) ;rn out.println( "Exception: " + e + "" ) ;rn e.printStackTrace() ;rn rn out.println( "CLASSPATH = " + classPath + "" ) ;rn rnERROR'srnOnce you understand the above, you shouldn't have much trouble, but you may still get errors. Unfortunately the error messages provide very little information to help you debug the error. rnJRun rnjava.lang.NoClassDefFound rnrnjava.lang.ClassNotFoundException rnrnjava.lang.NoClassDefFound rnThis is a sinister little error message. If your servlet has trouble finding a class, it may report this error. In JRun there is added confusion because sometimes the error message is reported on the HTML page, and sometimes java.lang.ClassNotFoundException is thrown instead and it is logged in the JRunServletError.log file. rnrnGenerally when I am using JRun, I open four shells and run tail -f JRunXXXXX.log in each one of them. There are four log files, hence four shells. The tail -f command will basically stream the contents of the file to the terminal window as it comes in, so you can see it. If you are on WindowsNT, you can get the gnuwin32 tool kit free from cygnus.com which will give you tail and other useful commands to make up for DOS's complete incompetence. rnrnIf you get the first error message, "java.lang.NoClassDefFound" god help you. Bang your head and scream and ask the computational gods what you did to deserve this fate! rnrnUpon finishing your lamentation, you should rerun the servlet and it will add a little bit more information the second, and succeeding times. It will give a class name. rnrnfirst time: rnrn java.lang.NoClassDefFoundrn rnupon immediately "Reload" rnrn java.lang.NoClassDefFound: Foorn rnThe class name that it gives is NOT the class it can not find. It will not tell you which class it can not find, but the mystery class is one that is used by the class that it appends to the error message if you reran it as suggested above. You get this error message on the HTML page, and generally get no error message in the JRunServletError.log. This is most unfortunate because the error information that comes in the log when you get a java.lang.ClassNotFoundException does let you figure out which class was not found. The information on the HTML page only indicates where to start looking. rnrnThis is definitely an area that should be improved. You may have hundreds of supporting classes inside the class that was reported. The possible cause of this error may be that the class wasn't found, or that the servlet engine did not have permission to read the class file, or any of its parent directories. rnrnIf you get the second error message, java.lang.ClassNotFoundException you should be able to see, in the JRunServletErrorLog, the exact line on which the program failed, and thus determine the offending class. You will not see an error on your HTML page, so knowing that you have this error means frequent checking of the logs whenever you have trouble. This is why I recommend "tailing" the log files. rnrnrnJWS java.lang.NoClassDefFound java.lang.ClassNotFoundException rnThe best way to run JWS when doing development is in a seperate shell where it can output to its heart's content. If you are on WindowsNT, this means do NOT run it as a service. If you are a developer you never want to run anything as a service on NT, until you have to. That way you have a chance of getting a nice java.lang.ClassNotFoundException in the shell where you launched JWS. If you get it, you can find the source of the error. Again, you will probably get the same error whether its really a missing class, or just one that the servlet engine doesn't have permission to read. Remeber the servlet engine is run as a user different than what you might be. It will have its own CLASSPATH and permissions. rnI have never seen the java.lang.NoClassDefFound error in JWS, though maybe I just haven't looked hard enough. More often, with JWS, I just get the "Docment Contains No Data" error thrown up by the browser. See below. rnrnDocument Contains No Data rnThis error message is put up by your browser when the servlet has crashed before it sent any information to the output stream ( the browser ). Under JWS it may come up in other cases as well, but generally the reason for it is the same. ( see below ) rnCheck the error log files. The most common reason for this is that some class was not found, or some method was called that no longer exists. In JWS, you generally have no idea how to find the source of the problem, except to recompile everything. In JRun, I think you will get more information in the JRunServletError.log file, and I'm hopeful that the debugger from LiveSoftware will give even more information. I haven't tried it yet. rnrn 论坛

没有更多推荐了,返回首页