[DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

["Rob S." <rs...@sfu.ca>]

Ahhhh, maybe I should add this to the INSTALL.txt file - unset your
CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
where the admins have conveniently set a system-wide CLASSPATH containing an
XML parser, etc.

- r

On Fri, 20 Jul 2001 12:59:01 +0100 tomcat-dev@jakarta.apache.org wrote:
> Guys,
> I've copied in an email returned to a support desk regarding a problem
> similar to this. There is a link to mikal.org that explains it in better
> detail, but essentially it refers to where your classes are found, as to
> what classloader they inherit. And the solution we found (similar to the
> post) is to ensure your classpath is unset before starting Tomcat.
> 
> Regards,
> Andrew Mc.Ghee
> 
> > Thanks again for your help on this,
> > Looks like we have tracked down the problem, and it was due to a
> reference to the Poet SDK on the CLASSPATH. References to > Poet code was
> finding the class instance on the jar file specified within the CLASSPATH
> itself, and so was not having
> > access to the classloader from tomcat, making anything within
> webapps/WEB-INF/lib unavailable. We have simply removed the
> > reference to the poet jar files from the classpath, and placed the jar
> file within the webapps/WEB-INF/lib directory, and
> > voila! (No need to set the database classloader now either)
> 
> > Thanks again for your assistance in this, pointing out the classpath
> loading help to isolate the problem.
> 
> > A useful link regarding this problem was;
> http://mikal.org/interests/java/tomcat/archive/view?mesg=22444 (And
> probably > explains the situation far better than I can)
> 
> -----Original Message-----
> 
> -----Original Message-----
> From: David Rees [mailto:dbr@greenhydrant.com]
> Sent: 19 July 2001 22:27
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [3.2] JSP Compiling Classpath issues -- finding
> WEB-INF/classes
> 
> 
> (Sorry about the double-qoute, I missed the original message)
> 
> > > -----Original Message-----
> > > From: Will England [mailto:will@mylanders.com]
> > > Sent: Thursday, July 19, 2001 10:49 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: [3.2] JSP Compiling Classpath issues -- finding
> WEB-INF/classes > >
> > >
> > > Greetings!
> > >
> > > Over on tomcat-users, theres been a discussion on JSP's finding the
> > > WEB-INF/classes directory when compiling.  They can't.  From searches,
I
> > > understand this issue has come up before in regards to the Coocon
> project.
> > >
> > > The root problem is that Jasper cannot find classes located in
> > > WEB-INF/classes of the web application that the JSP's belong to.	This

> > > occurs when a JSP is either first deployed or the TOMCAT_HOME/work
> > > directory is cleared, requiring a recompile of the JSP's.
> > >
> > > The system is Tomcat 3.2 under Apache with mod_jk, running on SunOS
2.7
> > > with JDK 1.2.
> 
> I have noticed the same problem while doing some development using
> Tomcat 3.2.[23].  I worked around it by making sure that I unset the
> classpath before calling startup.sh, then things seemed to work properly
> and classes were found as expected.
> 
> It seems that certain combinations of classes in different ares
> (CLASSPATH, WEB-INF/lib, or other) will break things, but I haven't
> pinned it down, so it could simply be user stupidity.
> 
> -Dave

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Rees <db...@greenhydrant.com>]

On Fri, Jul 20, 2001 at 12:47:51PM -0500, David Haraburda wrote:
> I don't think unsetting your CLASSPATH is necessary, especially since other
> applications may rely on it.  I would guess that most problems occur when:
> 
> 1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them
> to be loaded by the system class loader, not the Tomcat web app class loader, which
> causes problems)
> 
> or, as the case would appear to be with the POET sdk referred to before,
> 
> 2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib
> directory, but unbeknownst to you, there is actually another JAR (perhaps an older
> version of the software) sitting in your classpath, which gets loaded first.
> 
> Remember, a classloader always asks it's parent classloader to load a resource first,
> and then only loads it itself if the parent cannot find it.
> 
> Just make sure things your web application requires are in your WEB-INF/libs directory,
> and not in your classpath.
> 
> Craig McClanahan has two good posts about this:
> 
> http://mikal.org/interests/java/tomcat/archive/view?mesg=22444
> http://mikal.org/interests/java/tomcat/archive/view?mesg=8512

Thanks for the tips, what you've described is the exact behavior I've experienced.  
I just haven't had the time to read up about classloaders and the order which 
classes are loaded.

> As far as logging goes, you may want to check out the <Logger> elements is your
> server.xml file. They provide a good way to keep your terminal un-cluttered. :-)

Crap, I never really noticed this one before:

    <Logger name="tc_log"
            verbosityLevel = "INFORMATION"
    />

Is there any other tricks I've been missing for a while with Tomcat?

(I know, getting off-topic for tomcat-dev)

Thanks,
-Dave

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Haraburda <da...@haraburda.com>]

I don't think unsetting your CLASSPATH is necessary, especially since other
applications may rely on it.  I would guess that most problems occur when:

1) You add things you have in your WEB-INF/classes to your CLASSPATH (thus causing them
to be loaded by the system class loader, not the Tomcat web app class loader, which
causes problems)

or, as the case would appear to be with the POET sdk referred to before,

2) Your web application requires a certain JAR that you have placed in your WEB-INF/lib
directory, but unbeknownst to you, there is actually another JAR (perhaps an older
version of the software) sitting in your classpath, which gets loaded first.

Remember, a classloader always asks it's parent classloader to load a resource first,
and then only loads it itself if the parent cannot find it.

Just make sure things your web application requires are in your WEB-INF/libs directory,
and not in your classpath.

Craig McClanahan has two good posts about this:

http://mikal.org/interests/java/tomcat/archive/view?mesg=22444
http://mikal.org/interests/java/tomcat/archive/view?mesg=8512

As far as logging goes, you may want to check out the <Logger> elements is your
server.xml file. They provide a good way to keep your terminal un-cluttered. :-)

David

David Rees wrote:

> On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote:
> > Ahhhh, maybe I should add this to the INSTALL.txt file - unset your
> > CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> > where the admins have conveniently set a system-wide CLASSPATH containing an
> > XML parser, etc.
>
> I think it's the safe thing to do.  I think Tomcat 3.3 and Tomcat 4 both do this by
> default.  For Tomcat 3.2.X, I do this in custom startup scripts which make
> startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per
> host.  I also modify bin/tomcat.sh to redirect stdout/err to log files instead of
> cluttering the terminal.  If anyone is interested, I can send copies of the scripts
> and the patch to tomcat.sh...
>
> I would at least like to see the stdout/err patch integrated into Tomcat, I just
> don't know if there's much interest in including it into Tomcat 3.2.
>
> -Dave

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[David Rees <db...@greenhydrant.com>]

On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote:
> Ahhhh, maybe I should add this to the INSTALL.txt file - unset your
> CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> where the admins have conveniently set a system-wide CLASSPATH containing an
> XML parser, etc.

I think it's the safe thing to do.  I think Tomcat 3.3 and Tomcat 4 both do this by
default.  For Tomcat 3.2.X, I do this in custom startup scripts which make
startup/shutdown a lot easier if you're maintaining multiple copies of Tomcat per
host.  I also modify bin/tomcat.sh to redirect stdout/err to log files instead of
cluttering the terminal.  If anyone is interested, I can send copies of the scripts 
and the patch to tomcat.sh...

I would at least like to see the stdout/err patch integrated into Tomcat, I just 
don't know if there's much interest in including it into Tomcat 3.2.

-Dave

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

[Will England <wi...@mylanders.com>]

On Fri, 20 Jul 2001, Craig R. McClanahan wrote:
> On Fri, 20 Jul 2001, Rob S. wrote:
> > Ahhhh, maybe I should add this to the INSTALL.txt file - unset your
> > CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> > where the admins have conveniently set a system-wide CLASSPATH containing an
> > XML parser, etc.
> > 
> The standard Tomcat 4 startup scripts already ignore your CLASSPATH
> variable, and reconstruct one tuned to its needs.  If you want to make
> application classes available to all web apps, put them (unpacked) into
> $CATALINA_HOME/classes or in JAR files under $CATALINA_HOME/lib.

So, does that cross-apply to having all of your classes from /classes and
/lib available for the JSP's to use when being compiled by Jasper?

Will

Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 20 Jul 2001, Rob S. wrote:

> Ahhhh, maybe I should add this to the INSTALL.txt file - unset your
> CLASSPATH before starting TC?  I've logged into my fair share of *nix boxes
> where the admins have conveniently set a system-wide CLASSPATH containing an
> XML parser, etc.
> 

The standard Tomcat 4 startup scripts already ignore your CLASSPATH
variable, and reconstruct one tuned to its needs.  If you want to make
application classes available to all web apps, put them (unpacked) into
$CATALINA_HOME/classes or in JAR files under $CATALINA_HOME/lib.

Craig