if you use a ThreadPoolExecutor class
then implement the methods:
/**
* Method invoked prior to executing the given Runnable in the
* given thread. This method is invoked by thread <tt>t</tt> that
* will execute task <tt>r</tt>, and may be used to re-initialize
* ThreadLocals, or to perform logging. Note: To properly nest
* multiple overridings, subclasses should generally invoke
* <tt>super.beforeExecute</tt> at the end of this method.
*
* @param t the thread that will run task r.
* @param r the task that will be executed.
*/
protected void beforeExecute(Thread t, Runnable r) { }
/**
* Method invoked upon completion of execution of the given
* Runnable. This method is invoked by the thread that executed
* the task. If non-null, the Throwable is the uncaught exception
* that caused execution to terminate abruptly. Note: To properly
* nest multiple overridings, subclasses should generally invoke
* <tt>super.afterExecute</tt> at the beginning of this method.
*
* @param r the runnable that has completed.
* @param t the exception that caused termination, or null if
* execution completed normally.
*/
protected void afterExecute(Runnable r, Throwable t) { }
and there you call Application.set() and Application.unset()
(yes i know it is not public api but it should be fine to call)
On Fri, May 21, 2010 at 13:34, Objelean Alex <alex.objel...@gmail.com>wrote:
> I actually do use a tread pool, but didn't include it in pseudocode for
> sake of simplicity. Anyway, the problem is the same. As long as Application
> instance is not available from the created thread, you cannot use
> @SpringBean field reference because it needs Application to lookup spring
> bean. If you have a different approach for this problem, I'm very open to
> see it.
>
> Alex
>
>
> On 21 May 2010 00:21, Johan Compagner <jcompag...@gmail.com> wrote:
>
>> But this is a very bad design you should use a thread pool for this and
>> not just start new threads when a button is pressed.
>>
>> So this change makes it easier to program badly....
>> Beter would be to have a wicket managed threadpool...
>>
>> ----- Original message -----
>> >
>> > I do not agree...
>> > Maybe you didn't understand completely the use-case:
>> >
>> > public class MyPage extends Page {
>> > @SpringBean
>> > private MyService service;
>> > //perform a polling of long running process triggered by a button
>> click
>> > onClickButton() {
>> > new Thread() {
>> > run() {
>> > service.executeLongRunningProcess();
>> > }
>> > }.start();
>> > }
>> > }
>> >
>> > The following example won't work well if the Application is not stored
>> in
>> > InheritableThreadLocal. The reason why it doesn't work, as I understand
>> > that, is because @SpringBean lookup depends on Application instance
>> which is
>> > not accessible from within the thread. Having it stored inside of ITL
>> would
>> > solve the problem.
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp2222388p2225232.html
>> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >
>>
>>
>
