On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes < adrian...@gmail.com> wrote:
> I can't, however, do it now. But I would have no reason to do it knowing > some folks just consider a normal thing restart the container to update the > application. So if Wicket devs are in this way, I could write no quickstart > to convince. > Cara, agora você está sendo um grande babacão... What they are trying to say is that there is no reason to believe that there is an issue regarding the InheritableThreadLocal and application redeploys, but your *unproven* doubt, thus submitting a test case would make the issue clear. Guice, by its use of thread locals, and considering that Java thread locals > are not ideal, have the same type of bug. They could solve it with an API to > close a thing, but they don't. They could ship some fancy classes that may > work (accordingly to old @crazybob says) in some cases but they also didn't. > So if you redeploy an app with Guice in Tomcat, it logs about a thread local > leak. > Is Guice's issue related to child thread creation (thus related to our issue)? Or is it just some clean-up they don't do (which is not related to our issue at all)? > It's going to do the same thing with Wicket. > Only if you leave request-created threads to run indefinitely. But this would be a bug in *your *code, not in Wicket.
