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