There is a choice when pre-compiling JSPs. 1. Compile to "real" servlets. This involves precompiling the JSPs to classes and adding mappings to the web.xml so they execute just like other servlets. This cuts the JspServlet out of the picture and the JSPs are executed the same as other servlets.
2. Pre-populate Tomcat's "work" directory. This also involves precompiling the JSPs to classes, under the "work" directory, but continues to use the JspServlet to execute the JSPs. The critical point is that the expected packages to which the JSPs are compiled are different between these two choices. The JspServlet expects every JSP to be compiled into the org.apache.jsp package. Thus, every index.jsp is expected to be compiled as the org.apache.jsp.index_jsp class, even though the class file may be in various subdirectories, for example "dir". The JspServlet avoids the obvious naming collisions by loading each JSP class into a separate classloader. (Nice trick, but can make life tough for debuggers.) For choice 1, the JSPs need to be compiled into a directory structure where the package matches the directory structure in the standard Java way. Each JSP's fully qualified class name would need to be unique and entered into the web.xml. The error below appears that the index.jsp in question has been compiled sort of per choice 1, but is being run under choice 2. The class file appears to be at the right location under the work directory, but it was compiled to the wrong package, i.e. the package includes "dir", when it shouldn't. I don't use JspC, so I can't help much with respect to its use. I'm currently not sure about its usability state in the various Tomcat releases. In the past, it has had difficulting getting the package right in the context of these two choices. I would think that in the current releases, it can be coaxed into doing the right thing for one or both of these choices, but I can't say much more than that. However, I have used the Ant jspc task along with the javac task to accomplish choice 2 without much difficulty in a number of different Tomcat 4.1 releases. I would assume there would be no problems as well in the current Tomcat 5 release, but I haven't actually tried it yet. Cheers, Larry > -----Original Message----- > From: Antony Paul [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 8:46 AM > To: Tomcat Users List > Subject: Re: Problems running pre-compiled JSP classes when > in subdirectories > > > The generated servlets are not put in a package. When Tomcat > is compiling > JSP it is put in org.apache.jsp. How to set this in the jspc task. > The files are generated as usual in the work directory in the > same structure > as Tomcat itself compiles JSP files. > > Antony Paul > ----- Original Message ----- > From: "Ralph Einfeldt" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > Sent: Wednesday, January 07, 2004 7:06 PM > Subject: RE: Problems running pre-compiled JSP classes when in > subdirectories > > > May be you should have a look at the following: > > - the package statements in the generated source files > - the file structure of the generate class files > > > -----Original Message----- > > From: Jay Glanville [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 07, 2004 2:20 PM > > To: 'Tomcat Users List' > > Subject: Problems running pre-compiled JSP classes when in > > subdirectories > > > > > > > > Here's my application's background. I have two files: > > <WEBROOT>/index.jsp > > <WEBROOT>/dir/index.jsp > > java.lang.NoClassDefFoundError: org/apache/jsp/index_jsp > (wrong name: > > org/apache/jsp/dir/index_jsp) > > at java.lang.ClassLoader.defineClass0(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:537) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:448) > > at > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
