Hi Rafael,

I didn't completely understood your async solution but the following looks suspicious:

  public class DemoPage extends WebPage implements IRunnableFactory {
    @Override
    public Runnable getRunnable() {
        return new GenericTask(...) {
            @Override
            public void run() {
                ...
                error(new ResourceModel("some.resource").getObject());
            }
        };
    }
  }

Your Runnable holds a reference to a Wicket component, that is a no-go!
First as you've already noticed there will be no application attached to the current thread. But that page might never be rendered again and/or is probably already serialized to disk or somewhere else. Who knows whether #error() needs access to the current application? What happens with race conditions because a web request is currently stepping through the page while you try to add a new error?

You should move your asynchronous code out of Wicket components, as these should not be touched from outside of a web request thread.

Moving feedbackMessages to IModel might be an improvement (I didn't check this). But your example is not a good advocate for it.

Sven


On 09/17/2013 04:49 PM, Rafael W. wrote:
Hello everybody,

I would like to put https://issues.apache.org/jira/browse/WICKET-5353 to dicussion. Attached, you can find an example of a Wicket application that would benefit from that change. (Simly run wicket-async-task-demo with jetty:run in Maven.)

Generally, I want feedback messages to be represented by models rather than by Serializables in order to allow more multithreading in Wicket. The example contains a simple progress bar component where tasks are run in background threads in order to keep the Wicket application responsive. (I mostly use Wicket in Desktop-style applications where the attached component is tremendously useful for me.)

The problem with the Serializable solution for feedback messages is that the messages have to be assembled at the time the error occurs, not at the time the message is to be displayed. In my believe, this is a misconception that can easily be corrected. I described the topic further in the Jira issue above.

Thank you for your feedback.
Regards, Rafael Winterhalter


Reply via email to