well actually can be a link with cxf. Just trying to see it ATM and just saw the behavior you describe. Will come back if I find something wrong due to tomcat otherwise just assume it was a wrong cxf setup and sorry me to have sent this mail a bit too early. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2014-04-03 23:31 GMT+02:00 Mark Thomas <ma...@apache.org>: > On 03/04/2014 18:31, Romain Manni-Bucau wrote: >> Hi guys, >> >> just saw setParentClassLoader is deprecated on WebAppClassloader. >> Comment is "not used in tomcat 8". >> >> The question is: how does tomcat handle reloading. With tomcat 7.0.53 >> impl when reload is hit parent loader is set to null and once >> restarted the loader is quite broken. > > "loader" and "class loader" are different. The Context has a reference > to a Loader instance which in turn has a reference to a > WebappClassLoader instance. You need to be precise about your language > so others can understand the point you are trying to make. > > There is no parent "loader". I assume you mean the parent field of the > WebappClassLoader which is an instance of ClassLoader. > > When a web application is reloaded, the old WebappClassLoader instance > is thrown away when Context is stopped and a new instance created when > the Context is re-started. The old instance should not be used once the > Context has been stopped so the fact that WebappClassLoader.parent is > set to null during stop() should be irrelevant. > >> Does tomcat 8 handles it recreating the loader? > > It isn't clear what you mean by the above question. Broadly, Tomcat 8 > behaves the same way as Tomcat 7. > >> Will tomcat 7.0.53 be >> fixed for this usage (wtp uses it for instance)? > > What usage? It isn't at all clear what you think is broken. If reloading > in general was broken I'd expect to see a lot of complaints on the users > list. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org