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