Hey Bernard, thank you for your extensive and constructive help. Basically, this is what I am doing now. In my initial solution, I already wrote a LoadableDetachableModel<Future<T>> which can receive futures which are again managed by a Spring bean.
Since the futures provide exceptions via the Future.get methods, I check if the exceptions are of type WicketResourceWrapperException which wrap the original exception and additional provide a String with the resource key. If the requesting thread discovers such an exception, the thread registers the resource key in form of a resource model. Also, this solution only adds a manageable amount of boilerplate. All this just for the archives. Maybe someone else runs into the same problem one day. Best, Rafael 2013/9/20 Bernard <[email protected]> > Hi > > Please let me explain how I would do this in simple terms. > > With Java EE Web, or with web applications in general, executions are > request/response based. Doing it differently is not likely to succeed. > > Even when you create the illusion of server-initiated GUI updates, you > use polling on the client. > > So the poll request is the natural candidate to update the GUI. > > Any long running thread must be totally decoupled from the GUI and > must not even know anything about the polling request. The request > must know about some identity kept inside the thread so some > association can occur. > > After the long running thread is started, a polling request may call a > method of a service that can collect the results that the thread may > have produced asyncronously before. > > So the question remains where the long running thread resides. Just > pick a standard method for this such as Java EE @Asynchronous or the > message-driven bean. It is probably easiest to let @Asynchronous > update a database table and let the poll request read the data. > > Otherwise this is going to be rather messy if you want to do this in a > scalable way within a simple servlet container. > > You can check how others implemented this, e.g. > > > http://stackoverflow.com/questions/1979277/solution-to-the-long-running-query-problem-in-a-web-application-asynchronous-re > > Regards, > > Bernard > > > On Thu, 19 Sep 2013 15:41:46 +0200, you wrote: > > >>I consider writing an alternative implementation ... but I guess there is > >>no better way? > > > >It will be the better solution. > > > >> I still do not get > > > >Still clinging :P > > > >> why it is a difference if Session adds a feedback message > asynchronously to > >> some third request thread compared to if some custom background thread > does > > > >IIRC the problem was not any synchronization issue but unset threadLocals: > >When messages are added to the session or to a component, the > threadLocals are set. When you do the same from your custom background > thread the threadLocals are not set. > > > >> keep a temporary reference to the session in a custom background thread > > > >Please don't do that: The reference to a session object is valid for the > duration of a single request only. > > > >Regards > >Sven > > > > > >On 09/19/2013 03:19 PM, Rafael W. wrote: > >> I consider writing an alternative implementation where a thread-safe > >> component works as a mediator for feedback messages such that the > >> Wicket-thread can poll them from this thread-safe component. It's not > the > >> most beautiful solution since it generates quite some boilerplate which > >> must in addition be explained to every developer, but I guess there is > no > >> better way? > >> > >> By the way, I am not clinging to my solution. I ask all this, because - > at > >> least for me - the Wicket source code is not always easy to follow. I > just > >> wanted to know the background for these decisions in order to find a > better > >> solutions since I was not aware of the exact reasons for the > >> synchronization of the method. I read the code and obviously made some > >> wrong assumptions over it which were corrected now. I would not know > where > >> I would get answers to these questions other than from this mailing > list, > >> this is why I am asking. > >> > >> PS: From your answer, I still do not get why it is a difference if > Session > >> adds a feedback message asynchronously to some third request thread > >> compared to if some custom background thread does the same. Wouldn't > this > >> mean that I could simply keep a temporary reference to the session in a > >> custom background thread and call Session.error instead? > >> > >
