What itch are we trying to scratch, here, anyway? When do folks need access to the Application object outside of a request thread? What is the usecase?
On Wed, May 19, 2010 at 3:30 PM, Adriano dos Santos Fernandes <[email protected]> wrote: > On 19/05/2010 16:16, Johan Compagner wrote: >> >> >> ----- Original message ----- >> > On 19/05/2010 13:06, Alex Objelean wrote: >> > This currently make web-classloader leaks. If you start using >> > InheritableThreadLocal's with arbitrary objects, you're going to make >> > even more leaks. >> > >> > Also note, there is something not good here. AFAIK, Wicket sets the >> > thread locals only during the request. But if child threads are spawned, >> > they can't be cleaned automatically. IMO, it should be done something >> > that the user needs to call to set/clear this, like a specialized >> > WicketThread class. >> >> And when should that one clean up the threadlocal?? >> What would be a good time to clean it up? >> > That the user decides. Wicket could allow it to set/clear the TLS > application. > > I do not think the application object is general enough to be passed > implicitly to threads. > > BTW, can't a web application have more than one Wicket filters and then more > than one application object? In this case, threads shared by the web > application would have "arbitrary" application objects. > >> But threads that are created in a request should finish and terminate at >> one point and never be reused. >> > I already shown Java 1.4 bug. They seems not interested to change it, so you > deal with it, you say "Java is bad", or you're part of the "restart is ok" > people. > > > Adriano > >
