Agreed - I use pools for stuff like this. But, it's not broken for pools - nothing functionally changed, right?
Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -----Original Message----- From: James Carman <ja...@carmanconsulting.com> Sent: Wednesday, May 19, 2010 9:28 PM To: dev@wicket.apache.org Subject: Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal It solves that one particular usecase, but I doubt folks would be starting threads like that. Most folks, if they're smart, would use a thread pool for something like that. For the pooled thread case, it doesn't work. On Wed, May 19, 2010 at 9:29 PM, Jeremy Thomerson <jer...@wickettraining.com> wrote: > It solves this problem, which is specifically why it was requested: > > onClickOrSomethingSimilar() { > new Thread(new Runnable() { > void run() { > doSomethingWith(Application.get()); > } > }).start(); > } > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Wed, May 19, 2010 at 6:28 PM, James Carman > <ja...@carmanconsulting.com>wrote: > >> Sure this might work, but then again you wouldn't need the >> InheritableThreadLocal for this. The question is, does the >> InheritableThreadLocal really solve anything? Is it really addressing >> the problem? Or, would you have to do code like this to manage it >> properly anyway? And, if so, then why implement the >> InheritableThreadLocal, especially since we've shown that it will fail >> in more cases than it will work? >> >> On Wed, May 19, 2010 at 6:28 PM, Johan Compagner <jcompag...@gmail.com> >> wrote: >> > If you where using threads in your application >> > Then i would do it this way: >> > >> > Your WebApplication class has a method: >> > getExecutor() that returns a ThreadPoolExecutor >> > >> > That threadpoolexecutor (that you extend) overrides 2 methods >> > >> > protected void beforeExecute(Thread t, Runnable r) { } >> > >> > that sets the thread locals (so the application instance that has the >> > executor) and >> > >> > protected void afterExecute(Runnable r, Throwable t) { } >> > >> > to release all thread locals. >> > >> > this way you use a pool (way better to control your web application) and >> all >> > the resources you need are set just before and release right after. >> > >> > johanm >> > >> > >> > >> > On Wed, May 19, 2010 at 23:41, 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 >> >> >> > >> >
