why would a request thread start your executor pool? the pool would most likely be started from a context listener which uses a separate thread. the usecase for the inheritable is for short-lived threads started from a request thread.
-igor On Wed, May 19, 2010 at 2:41 PM, James Carman <ja...@carmanconsulting.com> wrote: > 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" <adrian...@gmail.com> > 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 >
