I wondered about this too: would this work with a job framework like Quartz? The thread is not started in a wicket context, but by the thing that quartz is managing. Therefore the inherited thing would not work and the Application would not be set.
Martijn On Wed, May 19, 2010 at 11: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 > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
