Classloading is a wacky wacky thing in java. With luck - you never need to worry about it, other times - you REALLY need to knoiw whats going on. That being said ...
Tomcat uses multiple class loaders. There are at least two reasons to do so
- security -- Classes can't jump over classloaders and invoke/use classes to do bad things
- Foundation for reloading webapps/jsp's/servlets and other similar crap
The classloader hierarchy can be found here for tomcat: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html
By using multiple classloaders, some classes have visibility to others, while some classes don't. (Yeah that sentence stunk)
When a new class is loaded via reflection or another mechanism - someone's classloader needs to do this. Using the wrong classloader causes really bad things to occur like NoClassDef found (which we see so often) which usually occurs when a class (or jar) is placed on the wrong spot on the hierarchy.
When java 1.2 came - all classloading got massively changed. Why? Use google to look that one up - the explanation I'd give would be more confusing. That is when Thread.getContextClassLoader() was introduced.
Hopefully this was enough information to help you answer the question.
But my whole point can probably be ignored if you give rid of the leading "/" for your getResourceAsStream() call. (I don't use getResourceAsStream(), so I sometimes forget the little, yet important, details.)
bad: getResourceAsStream("/more/cowbell.properties");
good: getResourceAsStream("more/cowbell.properties");
-Tim
Andy Scott wrote:
Thanks for that,
I've tried: this.getClass().getResourceAsStream("/" + name);
This is in a class within the jar.
What differences does the Thread.getContextClassLoader() offer?
It isn't a static call, how would I use that in an ordinary class?
Thanks in advance,
Andy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
