Will the inheritance of the application really work correctly? For pooled threads that are created at application startup, the threadlocal will be null, because the parent thread is the thread that starts the container. For threads that are created within the context of the request thread, they will get the current application object, which would be fine if that thread executes and finishes. But, for threads that are going to be reused (executor threads in a pool), they will see the original application object because the value is set at thread creation time. If you have multiple wicket filters in the same context, that could be incorrect, meaning a request thread for a different application submitted a task to be executed.
On May 19, 2010 4:13 PM, "Adriano dos Santos Fernandes" <[email protected]> wrote: On 19/05/2010 17:03, Jeremy Thomerson wrote: >> >> >> To clarify this, I use Application.set and App... Well, forgetting to unset it would not leak any more than have it implicitly set like it's going to be. And I do think forgetting this is developer fault. What you all do not want to understand is what I said about Java library spawning its own threads, and that is not documented, as its for cleanup in the case I shown. Adriano
