Hi Chris, Thanks for reminding. I'm fully aware of the separating to protecting mechanism, and some classes are loaded from top to down, like those starting with java and javax, and some are prohibited to be loaded from the webapp class loaders, like the servlet API classes like ServletDef, others are bottom to up. Actually I think I'm just doing the similar thing as what Tomcat is doing. I'm creating my URLClassLoader while Tomcat is creating the common class loader. So I think my instance of URLClassLoader is just a simple counterpart of the common class loader. And above them is the system/app class loader.
Would you correct me if my understanding is not accurate? Best regards, Elgs On Sep 26, 2012, at 3:19 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > Elgs, > > On 9/25/12 1:15 PM, Elgs Chen wrote: >> Hi Mark, >> >> I finally get my homework done. Thank you so much for pointing me to the >> right direction. That really helped me to gain huge insight into the inner >> world of the tomcat. >> >> I used JPDA to attach my eclipse to tomcat. Then I was able to see >> everything happens with the WebappClassLoader.loadClass. For my question, >> the key is to set the WebappClassLoader's parent class loader. Previously it >> was the system class loader, which is not intended. As this became obvious, >> I added a line to set the server's parent class loader, like this: >> >> final StandardServer server = (StandardServer) tomcat.getServer(); >> server.setParentClassLoader(TomcatMain.class.getClassLoader()); >> >> Now the server's parent class loader becomes my URLClassLoader, and that is >> the class loader being able to load all the jars I put in the lib directory. >> Then I start my Bootstrap, it works like a charm!! >> >> Mark, thank you so much. I really really appreciate you fast and kind help! > > Note that Tomcat separates ClassLoaders in this way to protect > "system"-level classes from being loaded by web applications. By > changing the parent ClassLoader, you are undoing that protection. > > -chris > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
