Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 735
  • Last Modified:

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
0
Farzad Akbarnejad
Asked:
Farzad Akbarnejad
  • 6
  • 5
  • 4
  • +2
2 Solutions
 
TimYatesCommented:
> 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
0
 
Farzad AkbarnejadAuthor Commented:
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
0
 
objectsCommented:
afaik all classes need to be in a package.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
searlasCommented:
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.
0
 
searlasCommented:
...you would then have to import the foo.bar package:
<%@ page import="foo.bar.*" %>
0
 
Farzad AkbarnejadAuthor Commented:
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
0
 
Farzad AkbarnejadAuthor Commented:
But I think that we can use beans without packaging them. Is there any way?

-FA
0
 
copyPasteGhostCommented:
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
0
 
Farzad AkbarnejadAuthor Commented:
>>Is there a reason you don't want to put your code into packages?

Just for learning :-)

-FA
0
 
copyPasteGhostCommented:
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
0
 
searlasCommented:
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)
0
 
copyPasteGhostCommented:
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
0
 
searlasCommented:
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.
0
 
searlasCommented:
Ghost,

Got a reference for that, out of interest?
0
 
searlasCommented:
Founds one myself...

It seems to be a difference between running on JDK1.3 and JDK1.4...

Why do I get " '.' expected" when my JSP is compiled?
The Javac bytecode compiler in J2SE 1.4.0 is more strict than in previous versions in enforcing compliance with the Java Language Specification, and thus rejects import statements that import a type from an unnamed namespace.

For example, if you have an import statement like the following, the compiler expects the imported class to be in a package. Therefore, the compiler assumes that MyBean is a package and expects the package name to be followed by a period (.) and either a subpackage or a class. To resolve the problem, put the bean in a package.

INVALID IMPORT STATEMENT:


<%@page import="MyBean" %>

VALID IMPORT STATEMENT


<%@page import="MyPackage.MyBean" %>


From:
http://www.netbeans.org/kb/faqs/web_apps.html#19
0
 
copyPasteGhostCommented:
great I was busy for a second didn't have time to going,
but yup I agree, :c)
Ghost
0
 
copyPasteGhostCommented:
was there anything else?
Ghost
0
 
objectsCommented:
As I said originally your classes/beans *must* be in packages :)
0
 
objectsCommented:
0

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 6
  • 5
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now