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

Reply via email to