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
