files in WEB-INF/classes not found?

[Chris Hanne]

I have a fresh CentOS VPS server. I installed JDK 1.6.20 and tomcat-6.0.26. I have about 7 virtual hosts that I moved over from another server. When I try to access a page that uses java classes I get a jsp compile error.

   
org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: 7 in the jsp file: /states/DESkatingRinks.jsp
RinkFactory cannot be resolved to a type

<%
     RinkFactory fac = new RinkFactory();

The RinkFactory class is in the proper directory for it's package inside WEB-INF/classes/com/rinks

I checked the classpath for the JSPs using:
<%=application.getAttribute("org.apache.catalina.jsp_classpath").toString()%>
and it does list the WEB-INF/classes as part of the classpath.

This code works on my local machine as well as my old server. I get a similar error for other classes on other jsp pages and cannot figure out why the classes are not found.

Thanks!

[Bear Bibeault]

Still putting Java code in JSPs?

In any case, did you import the classes from the proper package?

[Tim Holloway]

Hello, Chris, welcome to the JavaRanch.

My guess is that you're probably not only new to the JavaRanch, but probably fairly new to Java as well. As Bear has indicated, the use of scriptlets in JSPs - a la ASPs - is a discouraged practice these days. Scriptlets are great for False Productivity, because you can code quick-and-dirty, "Git 'R Dun!" stuff that displays pages in a hurry and makes it look like you're Accomplishing Things.

However, there's a significant price to be paid. Two of them, in fact. First, unlike compiled code, scripts (and scriptlets) aren't fully validated until they're executed. So it's possible to deliver massive projects which are actually total chunder and no one will know about the bad functions until they attempt to use them.

Secondly, long after the "quick" is gone, the "dirty" can grow into outright abominable. Large projects full of logic-ridden JSPs are horribly expensive to maintain. You save money up front, but end up spending it forever after. Which is why most enterprise-grade apps separate the Model, View, and Controller into separate components. It costs more time and money to design and develop, but the resulting product is more reliable, more secure, and easier to maintain.

There is a time and place for all things, but the time and place for JSPs with embedded logic in them these days is extremely limited. Personally, if I'm looking to do a slap-out web project, I'm like to forgo Java entirely and use something like PHP.

[Chris Hanne]

Hi,

I am not at all new to java, jsp, or struts. This was a test JSP and I put the code right into the JSP to test why it was not working when passed to the JSP in the request obj after forwarding from the struts action. Anyway, none of this has nothing to do with my question.

As I stated the clases are in the proper directory structure to match the package under WEB-INF/classes. After posting this last night I looked at the tomcat logs and it looks like tomcat is deploying every directory in my app as a seperate webapp. To test this I moved the JSP to the root and it works. Now the question is why is tomcat deploying every directory under my virtual host as a webapp.

Thanks.

[Tim Holloway]

Chris Hanne wrote:... the question is why is tomcat deploying every directory under my virtual host as a webapp.

Thanks.

Sorry. But it was your first post, and it's far more common for us here to run into "J-ASP"s, so to speak. I was just over in the JSP forum and I shrieked in horrror at some of the stuff I ran across.

For your problem, I think we need to see how you configured the virtualhost. My best guess is that you thought that you could put one and one only application into the virtual host and you specified its applications directory accordingly. However, a virtual host is still a host, and can contain many apps, so the webapps root for that host is going to behave the same way that the webapps directory does in the primary host. Meaning that each subdirectory of the webapps directory is deployed as an independent app.

However, that's just a guess, so if you'd be so kind as to post the relevant parts of your server.xml file, it would help.

[Chris Hanne]

Yes, I belive you are correct it is treating each directory as a webapp. For some reason this did not happen on the older server. I coppied the <Host> sections from the old server's server.xml. There is a difference in tomcat versions. Old was tomcat 5 and new is tomcat 6.

I think if I move everything into a folder called ROOT things will be OK but I did not have to do that on the old server. The apache document root was /home/webadmin/public_html and the tomcat host appbase was the same. I think I need here to set up

Apache: /home/webadmin/public_html/ROOT
Tomcat: /home/webadmin/public_html/ROOT

I have about 12 virtual hosts so that is a lot of moving files. I wonder if there is a param somewhere to tell tomcat not to deply and treat /home/webadmin/public_html ad the ROOT.

Thanks

[Tim Holloway]

I don't think that there's a substantial difference there in Tomcat 5, 6, or even 4, so I don't know how it managed to work before.

A hostcat host has a "webapps" directory which can be home to deployed webapps. You can deploy webapps without anything going into this directory, if you drop a WAR or exploded WAR into that directory, it will automatically be deployed.

If you drop the WAR in without qualifications, the webapp will be deployed under the same context name as the WAR (minus the ".war" extension, if it's a true WAR file). So if I plopped in a "myapp.war" file into Virtual Host #1's webapps directory, it would serve that webapp up under http://virtualhost.mydomain:8080/myapp", assuming no fancy reconfigurations.

There's a special case, however. The standard Tomcat server config is defined as having the webapp context "/" as being mapped to the exploded WAR named ROOT under the webapps directory (again, unless reconfigured). That's why things worked as they did. ROOT is just the default webapp for when your URL doesn't include a context name.

It's important to make the distinction between the webapps directory (TOMCAT_HOME/webapps) and the default context web application (TOMCAT_HOME/webapps/ROOT). One is a repository for webapps, the other is one of possibly many webapps. Each webapp is deployed at the top level withing the webapps directory. URL mapping to that webapp is done by default, or by applying a series of rules. Those rules actually include the ability to deploy webapps without them being copied to any child of the TOMCAT_HOME directory tree at all (which is how I deploy apps for testing). But that's not something you're doing.

[Chris Hanne]

OK I figured it out.

There are attributes that can be set in the Host definition in server.xml to turn off the default behavior. I tried setting them and everything works fine. Nothing is deployed and the classpath is fine. My apache virtual host and tomcat virtual host can now be in public_html.

<Host name="localhost" appBase="webapps"
unpackWARs="false" autoDeploy="false" deployOnStartup="false" >
</Host>

More details are in:

http://tomcat.apache.org/tomcat-6.0-doc/config/host.html

I think I want these turned off in production anyway.