I would give 50-50 odds that either JRun is non-conformant or the
spec is vague or silent on the packages the generated Java files are a part
of.  It does make sense though, for Tomcat to do it the way that it does.
You class name is your page name and your directory structure is your
package name.  Does JRun munge the directory structure and the page name
together to form the class name, I wonder.

        Randy


-----Original Message-----
From: Scott Tatum [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 4:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Strange custom class behaviour with subdirs in 3.2.1


You have solved my problem sir and I thank you! It all makes sense now that
you
have explained it. JRun 3.0, which implements the same servlet spec, didn't
need
the extra qualification. I wonder which one isn't following the spec? :-o
I'm
guessing JRun.

I have a printout of the 2.2 servlet spec right here. I needed to read it
anyway! Thanks again.

-Scott

Randy Layman wrote:

>         At the top of your JSP file, be sure to import StatsBean (i.e. <%@
> page import="StatsBean" %>).
> Tomcat assumes that all of your webapp is in one package structure, so
> creating a helpdesk directory causes the generated JSP to have a helpdesk
> package.  I don't know if this is in the spec, but I would imagine so.
> Anyways, you get your problem because the files in the root are in the
> default (blank) package, just like your class.
>
>         Randy
>
> -----Original Message-----
> From: Scott Tatum [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 10:50 AM
> To: [EMAIL PROTECTED]
> Subject: Strange custom class behaviour with subdirs in 3.2.1
>
> First, the obligatory setup info:
>
> Tomcat 3.2.1 using built-in webserver changed to port 80.
> RedHat 6.2
> Sun JDK 1.3.0_02
>
> I'm having a strange problem that I did not have while using JRun, and
> I'm hoping someone can shed some light.
>
> The situation is simple - say I have a webapp called blah. In blah's
> WEB-INF/lib directory I have a jar file with some classes that I use
> frequently. One of these classes is StatsBean. Then I have all my jsp
> files in the docBase and I can use the StatsBean fine.
>
> I also have a helpdesk directory off of the docBase (i.e.
> webapps/blah/helpdesk) which also needs to use the StatsBean. If I have
> a jsp file in the helpdesk directory that tries to declare/use a
> StatsBean, or any of my custom classes, I get this kind of error:
>
> (this example is a webapp called ct-dev whose context path is / and is
> compiling /helpdesk/helpdesk.jsp)
>
> org.apache.jasper.JasperException: Unable to compile class for
>
JSP/usr/tomcat/work/xxx.xxx.xxx.xxx_8080/_0002fhelpdesk_0002fhelpdesk_0002ej
> sphelpdesk_jsp_0.java:73:
>
> Class helpdesk.StatsBean not found.
>                  StatsBean statsBean = (StatsBean)
> session.getAttribute("statsBean");
>
> For some reason it thinks all my classes should be in a helpdesk package
> because the URI has helpdesk in it. Is this expected behaviour? I did
> not have this problem in JRun. I would expect to be able to use my
> classes anywhere in the web application, not just the app root. The
> problem manifests itself both with classes in the WEB-INF/classes dir,
> and classes in jars in the WEB-INF/lib dir.
>
> I'm certainly not counting out a configuration problem. If I need to
> post the contents of my configuration files I can. Of course, I don't
> really even know what all configuration files are used! As far as I can
> tell, the standalone tomcat only needs server.xml and web.xml. A lot of
> them seem to be only for mod_jk and/or mod_jserv. It's hard to tell from
> looking at the mass of config files in the conf directory what is needed
> by tomcat standalone, tomcat+apache, etc. It would be nice to have a
> document that explains every file in the conf directory and what it is
> needed for. That way I could do some cleanup and know that the files I
> have in there all have something to do with my setup. I have this
> feeling that several of them are jserv (i.e. not mod_jk) related and
> could be removed in most situations. Now watch someone point me to just
> such a file that probably comes with Tomcat. 8-)
>
> -Scott
>
> --
> Scott Tatum | [EMAIL PROTECTED]
> Senior Applications Developer, Special Projects
> WorldCom | http://www.wcom.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

--
Scott Tatum | [EMAIL PROTECTED]
Senior Applications Developer, Special Projects
WorldCom | http://www.wcom.com/



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to