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?
