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
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
