[depolitic]

I am learning JSP Servlets. I know some very basic java and I think I understand packages. But I am getting this error that makes no sense to me.

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

An error occurred at line: 133 in the jsp file: /index.jsp

Generated servlet error:
[javac] Compiling 1 source file

/Library/Tomcat/work/Standalone/localhost/depolitic/index_jsp.java:79: package com.depolitic.beans does not exist
com.depolitic.beans.cartoonbean cartoon = null;
--

now this is the path that I have;

com.depolitic.beans.cartoonbean.CartoonBeans.java

And this is the JSP I am using to call the bean:

<%-- start site banner bean --%>
<jsp:useBean id="cartoon" class="com.depolitic.beans.cartoonbean" />
<img src="images/banners/<c:out value="${cartoon.fileName}" />">
<%-- stop site banner bean --%>

Also the bean is correctly marked to belong to the :

package com.depolitic.beans.cartoonbean;

what am I doing wrong??? please help.

[Arkham_c]

How is your app deployed? Is it inside a war file, or an ear file, or just unrolled on the filesystem? If it's on the file system, are you sure your class is in the classpath?

[depolitic]

It is just on the file system, how do I get to add the class to classpath?

[Arkham_c]

Originally posted by depolitic:
It is just on the file system, how do I get to add the class to classpath?

Well, say your app is deployed here:

tomcat/webapps/myapp/index.jsp

The default classpath for this app would be:

tomcat/webapps/myapp/WEB-INF/classes/

If your class were there, it would be at this location:

tomcat/webapps/myapp/WEB-INF/classes/com/depolitic/beans/cartoonbean/CartoonBeans.class

If you have the class file at that location it should work. If it's somewhere else, you need to specify the classpath in the 'setclasspath.sh' script in tomcat/bin/

Hope that helps.

[absmiths]

Originally posted by depolitic:
/Library/Tomcat/work/Standalone/localhost/depolitic/index_jsp.java:79: package com.depolitic.beans does not exist
com.depolitic.beans.cartoonbean cartoon = null;
--

now this is the path that I have;

com.depolitic.beans.cartoonbean.CartoonBeans.java

<jsp:useBean id="cartoon" class="com.depolitic.beans.cartoonbean" />
<img src="images/banners/<c:out value="${cartoon.fileName}" />">
<%-- stop site banner bean --%>

I think we are missing the obvious here. Assuming that your classes are in the correct location, I would say that the useBean declaration is incorrect. You specify class="com.depolitic.beans.cartoonbean", but that is not the class name, that is the package name. I think what you want is class="com.depolitic.beans.cartoonbean.CartoonBean s" since that is the actual qualified name of the class.

[depolitic]

Thank you that fixed it - I had the package names and paths correct but.

After all this is was the simple not calling the bean correctly from the index.jsp page. You must name the class you are calling not only the package that class belongs to.

The other thing is that you have to manually compile the bean or servlet it will not recompile when you reload the jsp file.

I am using Tomcat and having to manually recompile my classes everytime I make a change is very tedius. I belive I will not have to do this once I move to a heaver container.

It is always the silly things, knocking my self senseless and all the time it is a simple little thing.

Thanks again.

Ps. I love the promise of JSP/Servlets/Beans but coming from a PHP background this is level of programming is totally another level of programming. I just wish it was not so complex. But what is complexity, but relative to experience.

[Arkham_c]

Originally posted by depolitic:
I am using Tomcat and having to manually recompile my classes everytime I make a change is very tedius. I belive I will not have to do this once I move to a heaver container.

We use WebLogic (very heavyweight container) and it doesn't compile your source for you. Typically you keep your source and your deployment separate.

You should take a couple of hours and learn ant (http://ant.apache.org). It will reduce your build process to a single step (can even integrate with tomcat and eclipse).

[absmiths]

Originally posted by depolitic:
The other thing is that you have to manually compile the bean or servlet it will not recompile when you reload the jsp file.

Yes, servlets and any other java classes must be compiled manually. The only part of the web application which is automatically compiled are JSP pages. Servlets may be automatically reloaded, but they will not be compiled for you.

I use Forte and have it place my work files in my WEB-INF/classes directory so that when I recompile from there the classes are immediately available to the servlet engine.

This behavior is common, by the way, and to my knowledge no J2EE container will perform this function for you. Besides, if you automate the build with Ant all will be well.

[Arkham_c]

Originally posted by absmiths:

I use Forte and have it place my work files in my WEB-INF/classes directory so that when I recompile from there the classes are immediately available to the servlet engine.

It's my understanding that you can get similar integration between Eclipse and tomcat.

As I said, WebLogic is the standard at my office, so I don't know from personal experience, but a friend of mine uses Tomcat at his office and raves about the eclipse integration.

[absmiths]

Originally posted by Arkham_c:
It's my understanding that you can get similar integration between Eclipse and tomcat.

As I said, WebLogic is the standard at my office, so I don't know from personal experience, but a friend of mine uses Tomcat at his office and raves about the eclipse integration.

I'm not really talking about integration - it is just a matter of setting up workspaces so everything works out.

Tomcat is integrated with just about everything under the sun by now.

[depolitic]

Hi


I am learning so please bear with me on this. I have two bean classes that are sitting in the following package structures.

First is the ValidationBean.java which sits here:

WEB-INF/classes/com/depolitic/beans/validationbean/ValidationBean.java

The ValidationBean.java bean is part of the package com.depolitic.beans.validationbean;

Then their is StringFormat.java that sits in:

WEB-INF/classes/com/depolitic/util/StringFormat.java

And the StringFormat.java sits in package com.depolitic.util;

As far as I know I am not doing anything wrong. But I get an error when I try to compile the: ValidationBean.java that calls methods from the StringFormat.java file. The error is:

/WEB-INF/classes/com/depolitic/beans/validationbean/ValidationBean.java:5: package com.depolitic.util does not exist
import com.depolitic.util.*;

What is wrong why cannot ValidationBean.java find the com.depolitic.util package.

As I am importing the package via import com.depolitic.util.*; in the top of ValidationBean.java


I am also declaring package com.depolitic.util;
in StringFormat.java

[Arkham_c]

Originally posted by depolitic:

As far as I know I am not doing anything wrong. But I get an error when I try to compile the: ValidationBean.java that calls methods from the StringFormat.java file. The error is:

/WEB-INF/classes/com/depolitic/beans/validationbean/ValidationBean.java:5: package com.depolitic.util does not exist
import com.depolitic.util.*;
...
As I am importing the package via import com.depolitic.util.*; in the top of ValidationBean.java

First, I think your problem is simply a classpath problem. What is your current directory when you do the compile? If you want it to work, you'll want to be compiling from /WEB-INF/classes/ like this:

javac com/depolitic/beans/validationbean/ValidationBean.java

Assuming you do that, it SHOULD work.

Two other things. First, it's a bad idea to do "import com.depolitic.util.*". Instead, explicitly import each class by name. This will help you a lot in case you do something like this (a contrived example, but you get the idea):

import java.util.*;
import java.sql.*;

Date d = new Date();

Hmmm... is that a java.util.Date or a java.sql.Date? If you import explicitly, you won't have to worry about such things.

Second, I would remind you not to build in your deployment directory. Instead, create a simple ant script, and make one of the targets copy your output to the deployment. You don't want to deploy your source for security reasons.

[depolitic]

Thank you so much.

I kept on compiling ValidationBean.java from with in the validationbean dir. So that is why I always got the could not find error. I was really getting frustrated. But the answer is so simple. Thanks.

Ant is something that a few people have recommended, and once I get my mind around the basics of J2EE then I will use it. But for now, I am just playing around. Your security point is very valid.

[absmiths]

Originally posted by depolitic:
Thank you so much.

I kept on compiling ValidationBean.java from with in the validationbean dir. So that is why I always got the could not find error. I was really getting frustrated. But the answer is so simple. Thanks.

Ant is something that a few people have recommended, and once I get my mind around the basics of J2EE then I will use it. But for now, I am just playing around. Your security point is very valid.

I second the import suggestion - try to be as specific as possible so that the code is more explicit. Ant is unrelated to J2EE by itself - it is a build tool that happens to have some J2EE extensions.

Anyway, if you keep using javac directly you need to become acquianted with the -classpath directive. When compiling the above example, you should use:

Code:
% /WEB-INF/classes>javac -classpath . com/depolitic/beans/validationbean/ValidationBean.java om/depolitic/util/StringFormat.java

In this case, the -classpath is not really necessary since you are at the root of your packages and you specify both source files for compilation, but classpath is a constant issue in Java.

Also, you should write shell scripts for these types of things so you don't have to keep writing the commands out.

[Arkham_c]

Originally posted by depolitic:

Ant is something that a few people have recommended, and once I get my mind around the basics of J2EE then I will use it. But for now, I am just playing around. Your security point is very valid.

And is really quite easy to use. You just write a simple XML file, and it will compile all your classes into the right directory, and even jar them up for you.

It's a java thing, not a J2EE thing. For most people, J2EE is a lot of overhead without a big gain. If you want to take your servlets to the next level, look into a MCV framework like struts. MCV (Model Controller View) helps you separate the presentation layer from the business logic. Very useful stuff.