Hi Adriano, If your application creates (or uses a library that creates) threads that don't die when the application is redeployed then you will have a memory leak no matter what Wicket does. If, on the other hand, all your theads are well behaved and die properly when your application is redeployed, you have no memory leak even with InheritableThreadLocal.
So using InheritableThreadLocal or not will not make any difference in this case. Regards, - Juliano On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes < adrian...@gmail.com> wrote: > On 19/05/2010 15:57, Jeremy Thomerson wrote: > >> Here's how you create a quickstart: >> http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/ >> >> If you find that there is a bug, you zip your quickstart directory and >> attach it to a JIRA issue. Then we fix it and build a new release and >> start >> a new vote (if the bug is serious enough). >> >> >> > I know, I know... For example, the ones I have in Jira and got closed > without analyze, or the ones I attached with fixes. > > 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. > > 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. > > It's going to do the same thing with Wicket. > > > Adriano > >
