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
>
