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
> >>
> >
>
