onClickOrSomethingSimilar() {
final Application app = Application.get();
new Thread(new Runnable() {
void run() {
doSomethingWith(app);
}
}).start();
}
On Wed, May 19, 2010 at 10: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
> > >>
> > >
> >
>
