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