Tomcat 5/ CLASSPATH issue

[Hichhiker]

I am not that familiar with tomcat, but I am launching an app that works in Resin on tomcat. I am trying to figure out why CLASSPATH does not seem to be working. I know tomcat default startup scripts are set up to overwrite environment CLASSPATH variable, so I edited the startup scripts to have my CLASSPATH in it (I would prefer not to have to do this). I can see the "-classpath" in the process listing and my classpath directory is the first one on the list. However tomcat is finding the files it needs in a different place (my files supposed to come first). Same exact CLASSPATH and files work fine with Resin, so it has to be something specific to how Tomcat handles classpath.

Is the a better (or "right") way to add classpath search directories to Tomcat? Any ideas? Thanks.

BTW, if it matters, I am running Tomcat 5.0.19 on Solaris9

Thanks

 

[byam]

Tomcat class loader, load from parent (Tomcat) first then child (webapps).

Check this out.

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html

 

[sedj]

Resources need by tomcat should be put in common/lib, shared/lib or context/WEB-INF/lib.

 

[Hichhiker]

Thanks for the replies, but I guess I did not make myself clear. I want classloader to pick up files with same name BEFORE it looks in my WEB-INF/classes - i.e. overwrite properties files, classes, etc. located in WEB-INF. "shared/classes" would be a nice place, but classloader looks there AFTER WEB-INF, which does not work for me.

I want to be able to run more than one instance of tomcat against same base code without having to re-copy the entire site to modify one small properties file.

Usually I've done this via CLASSPATH, but looks like Tomcat does not support that.

Thanks.

 

[sedj]

Firstly, you should defintely not have the same classes (qualified name) in two locations where a single ClassLoader will look at both. This is dangerous and bad practice.

Having said that, in Tomcat 3, classes in the TOMCAT_HOME/lib directory overrdide those in any context subdirs.
This is however not the case in tomcat 5 where the opposite is true (ie context resources override /common /shared ones).

Your only real solution is to not have two versions of the same qualified classes. If you cannot do that, then you should address your deployment strategy.