必须把servlet, service目录设在classpath中。

解决方案 »

  1.   

    to yyy_5(yyy_5):
        classpath是指什么?在哪?具体怎么设?麻烦解释详细一点好吗?!或者举个简单的小例子!不胜感激!!
      

  2.   

    service 改成 servlet !!!!!!!!!!!!!!!!!!!!!1
      

  3.   


    关于如何设置classpath的问题 ,一般不能编译时说找不到类的错误都是这个原因,请参考:http://expert.csdn.net/Expert/topic/490/490370.shtm
      

  4.   

    clathpath 
    借skyyoung的发表文章
    The 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. The basics 
    There are three places you set CLASSPATH information in JRUN and JWS. By 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. 
    HOME/servlets and dynamic class reloading 
    The /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. 
    If you want to do dynamic class reloading ( you probably do ) DO NOT put HOME/servlets in your USER_CLASSPATH !!! There 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. Since 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. If 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. Though 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. And 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." 
    Another 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. HOME/classes - static ( not dynamic ) reloading 
    If 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. 
    Classes 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. Technically, 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. You should be able to put .jar files or whaterver you want in the HOME/classes directory, though I've never tried. This from Alfred Werner at Thunderstruck .... ( speaking about JWS ) If 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. 
    On 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. USER_CLASSPATH ( or the User's CLASSPATH ) 
    In 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. 
    JRunConfig USER_CLASSPATH /home/foo/:/home/bar/:/usr/local/jdk/lib/: As the manual's Apache Notes says:           Note that these must be present in the main server configuration; 
              any of the following directives placed in a virtual server config 
              will be ignored:
        
    A virtual server config refers to additional "virtual" domain or host names that you may have configured your web server to answer to. For Netscape, it looks like you add a line like this to your obj.conf file: 
            Init classpath="d:/program files/livesoftware/jrunisapi/lib/jrun.jar;"
        
    JavaWebServer 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.                 setenv CLASSPATH "/home/foo/: ... "
        
    if you use bash you say something like this. 
                    set CLASSPATH="/home/foo/: ... "
                    export CLASSPATH 
        
    If you use WindowsNT, set the System classpath in the System Control Panel under the environment tab. The Servlet's CLASSPATH 
    So 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.         try { classPath = System.getProperty( "java.class.path" ) ; }
            catch ( Exception e ) 
              {
                System.out.println( "Exception: " + e ) ;
                out.println( "Exception: " + e + "" ) ;
                e.printStackTrace() ;
              }
            out.println( "CLASSPATH = " + classPath + "" ) ;
        
    ERROR's
    Once 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. 
    JRun 
    java.lang.NoClassDefFound java.lang.ClassNotFoundException java.lang.NoClassDefFound 
    This 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. Generally 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. If 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! Upon 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. first time:                 java.lang.NoClassDefFound
        
    upon immediately "Reload"                 java.lang.NoClassDefFound: Foo
        
    The 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. This 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. If 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. 
    JWS java.lang.NoClassDefFound java.lang.ClassNotFoundException 
    The 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. 
    I 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. Document Contains No Data 
    This 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 ) 
    Check 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.  
     clathpath 都不知道,不要说我是菜鸟噢,我也觉得我缺乏爱心
      

  5.   

    你可以参考一下mydomain目录下的setenv.cmd.也可参考samples\examples目录下的例子
      

  6.   

    to hexiaofeng(java爱好者):
      这是jsp的问题吗???????!!你也帮助回答回答吗!别尽待在一旁看热闹!谢谢了!!