Question

In our wicket application I need to start a long-running operation. It will communicate with an external device and provide a result after some time (up to a few minutes).

Java-wise the long running operation is started by a method where I can provide a callback.

  public interface LegacyThingy {
       void startLegacyWork(WorkFinished callback);
  }

  public interface WorkFinished {
       public void success(Whatever ...);
       // failure never happens
  }

On my Wicket Page I plan to add an Ajax Button to invoke startLegacyWork(...) providing an appropriate callback. For the result I’d display a panel that polls for the result using an AbstractTimerBehavior.

What boggles my mind is the following problem:

To keep state Wicket serializes the component tree along with the data, thus the data needs to be wrapped in serializable models (or detachable models).

So to keep the “connection” between the result panel and the WorkFinished callback I’d need some way to create a link between the “we serialize everything” world of Wicket and the “Hey I’m a Java Object and nobody manages my lifetime” world of the legacy interface.

Of course I could store ongoing operations in a kind of global map and use a Wicket detachable model that looks them up by id … but that feels dirty and I don’t assume that’s the correct way. (It opens up a whole can of worms regarding lifetime of such things).

Or I’m looking at a completly wrong angle on how to do long running operations from wicket?

Answer 1

I think the approach with the global map is good. Wicket also uses something similar internally – org.apache.wicket.protocol.http.StoredResponsesMap. This is a special map that keeps the generated responses for REDIRECT_TO_BUFFER strategy. It has the logic to keep the entries for at most some pre-configured duration and also can have upper limit of entries.