thinking about this more, in 1.5 these short-lived threads will not even be needed. most often you need to start a new thread so you have a properly configured wicket environment which depends on threadlocals. this environment is usually configured by wicket tester which sets up mock session, request cycle threadlocal. in 1.5 you can simply "push" wicket's threadcontext and replace it with a separate temporary one and when you are done simply pop it off. in 1.4 because all these threadlocals are seperate it is massier to manage them, thus its simply easier to do the work in another thread.
-igor On Wed, May 19, 2010 at 2:52 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > 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 >> >
