Re: [DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
On Fri, 20 Jul 2001, Craig R. McClanahan wrote: On Fri, 20 Jul 2001, Rob S. wrote: A, 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
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
[DOC] Re: [3.2] JSP Compiling Classpath issues -- finding WEB-INF/class es
A, 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: 19 July 2001 22:27 To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 10:49 AM To: [EMAIL PROTECTED] 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
On Fri, Jul 20, 2001 at 06:22:21AM -0700, Rob S. wrote: A, 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
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: A, 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