asked on

Problem with placing classes in root of WEB-INF\classes instead of WEB-INF\classes\package

Hello,
I am learning JSP and I want to run the Date example of J2EE Tutorial using Tomcat.
I am using JBuilder 9.0 with JDK 1.4 without any enviornment variabke setting in My Computer except the JAVA_HOME set.
My Date JSP has two classes: MyDate and MyLocales. When I placed them in a package like datepkg I haven't any problem. But when I place these classes on the root I got the following error when I want to run my jsp using Tomcat 4.1:

"C:\Program Files\JBuilder9\jdk1.4\bin\javaw" -classpath "C:\Program Files\JBuilder9\thirdparty\jakarta-tomcat-4.1.24-LE-jdk14\bin\bootstrap.jar;C:\Program Files\JBuilder9\jdk1.4\lib\tools.jar" -Dcatalina.home="C:/Program Files/JBuilder9/thirdparty/jakarta-tomcat-4.1.24-LE-jdk14" org.apache.catalina.startup.Bootstrap -config "C:\Documents and Settings\Farzad Akbarnejad\My Documents\Training\JSP\DateJSP\Tomcat\conf\server8080.xml" start
Apr 27, 2004 3:07:24 PM org.apache.coyote.http11.Http11Protocol init

INFO: Initializing Coyote HTTP/1.1 on port 8080

Starting service Tomcat-Standalone

Apache Tomcat/4.1.24-LE-jdk14

HostConfig[localhost]: Deploying configuration descriptor jb--default.xml

WebappLoader[]: Deploying class repositories to work directory C:\Documents and Settings\Farzad Akbarnejad\My Documents\Training\JSP\DateJSP\Tomcat\work

WebappLoader[]: Reloading checks are enabled for this Context

StandardManager[]: Seeding random number generator class java.security.SecureRandom

StandardManager[]: Seeding of random number generator has been completed

StandardWrapper[:default]: Loading container servlet default

StandardWrapper[:invoker]: Loading container servlet invoker

HostConfig[localhost]: Deploying configuration descriptor jb-datejsp.xml

WebappLoader[/datejsp]: Deploying class repositories to work directory C:\Documents and Settings\Farzad Akbarnejad\My Documents\Training\JSP\DateJSP\Tomcat\work\datejsp

WebappLoader[/datejsp]: Deploy class files /WEB-INF/classes to C:\Documents and Settings\Farzad Akbarnejad\My Documents\Training\JSP\DateJSP\datejsp\WEB-INF\classes

WebappLoader[/datejsp]: Reloading checks are enabled for this Context

StandardManager[/datejsp]: Seeding random number generator class java.security.SecureRandom

StandardManager[/datejsp]: Seeding of random number generator has been completed

StandardWrapper[/datejsp:default]: Loading container servlet default

StandardWrapper[/datejsp:invoker]: Loading container servlet invoker

Apr 27, 2004 3:07:25 PM org.apache.coyote.http11.Http11Protocol start

INFO: Starting Coyote HTTP/1.1 on port 8080

Compile failed; see the compiler error output for details.

      at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)

      at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)

      at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:317)

      at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)

      at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)

      at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)

      at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)

      at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)

      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)

      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

      at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)

      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

      at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)

      at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

      at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

      at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

      at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)

      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)

      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)

      at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)

      at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)

      at java.lang.Thread.run(Thread.java:536)

Thanks
-FA

TimYates

> When I placed them in a package like datepkg I haven't any problem. But when I place these classes on the root I got the following error when I want to run my jsp using Tomcat 4.1

Are the java files in a package too?

Do you take them out of their own package and recompile before you try to move them to WEB-INF/classes?

Tim

Farzad Akbarnejad

ASKER

Yes. I take them out of their package and place them in root and remove package statement from .java files and recompile them.

Thanks
-FA

SOLUTION

Mick Barry

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

searlas

When your JSP is compiled it is put into a package (dependent on the application server.) This put them into a different package to your java classes (which are compiled into the unnamed package).

You *may* be able to get things working by explicitly importing the classes ones by one:
<%@ page import="MyDate, MyLocales" %>
....

But, it would be better to leave the classes with a package statement, then copy the .class files into the classes subdirectory of your web app.

e.g.
package foo.bar;
public class MyDate {....}

Compile, and move to:
WEB-INF/classes/foo/bar/MyDate.class

where WEB-INF is under the root of your web application.

searlas

...you would then have to import the foo.bar package:
<%@ page import="foo.bar.*" %>

Farzad Akbarnejad

ASKER

searlas,

I test it with importing classes before. it give

"index.jsp": Error #: 200 : '.' expected

error in JBuilder. So I placed them in package.

Thanks
-FA

Farzad Akbarnejad

ASKER

But I think that we can use beans without packaging them. Is there any way?

-FA

copyPasteGhost

I don't think so...

Javabeans must be in a package that's one of the rules. Is there a reason you don't want to put your code into packages?
Ghost

Farzad Akbarnejad

ASKER

>>Is there a reason you don't want to put your code into packages?

Just for learning :-)

-FA

copyPasteGhost

ah well I was always taught that java programmers must place there code into packages for organizational purposes.
So I would suggest that you get used to that type of programming style so you can make good habits :)
there is nothing worse then 4 months later another co-worker has to go through your spagetti code and have to ask you to explain what you did and why you did it. I know it's happened to me several time :) So if I was you I would stick to writing structured code :)

Hope that helps,
Ghost

searlas

You should follow Ghost's advice, but for reference:

Section 8.2 of the JSP 1.2 specification states:

The JSP container creates a JSP page implementation class for each JSP page.
The name of the JSP page implementation class is implementation dependent.
The JSP page implementation object belongs to an implementation-dependent
named package. The package used may vary between one JSP and another, so
minimal assumptions should be made. The unnamed package should not be used
without an explicit import of the class.

(i.e. you CAN use classes from the unnamed package)

copyPasteGhost

searlas is right it can be done,
but and please experts correct me if I'm wrong..

tomcat version 5.x says that class files MUST be in a package..
so you might as well get used to it since that's the future.
Ghost

searlas

I had no problems with this:
Mank.java (compile and copy to WEB-INF\classes)
public class Mank {
public String getMessage() {
return "some message";
}
}

ugh.jsp:
<%@ page import="Mank" %>
<%= new Mank().getMessage() %>

Works fine.

searlas

Ghost,

Got a reference for that, out of interest?

ASKER CERTIFIED SOLUTION

searlas

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

copyPasteGhost

great I was busy for a second didn't have time to going,
but yup I agree, :c)
Ghost

copyPasteGhost

was there anything else?
Ghost

Mick Barry

As I said originally your classes/beans *must* be in packages :)

Mick Barry

:-)

http://www.objects.com.au/staff/mick