0
votes

So I have some Java code that takes some time to complete (about 2 minutes). Nothing I can do about that.

But I am wondering how best to approach this in the XPages UI so that the user may still have to wait but has more control/interaction while it is running (not just a spinning wheel).

So from what I can see I can do the following.

  • Java class called in XPage wrapped in a thread.
  • Java Agent called from XPage in a thread.
  • Java Agent called from an XPage, but waits for a document to be updated.
  • Eclipse plugin (For in the client) is activated. Not sure how it would talk back to XPage though (via document?).

Any other methods?

If you created the thread in the XPage, is that going to cause any problems at the server end? Will I have to avoid using Notes objects in the Java class?

2
Maybe this article by Mark Leusink can give you some inspiration? linqed.eu/?p=174Per Henrik Lausten
Also this one from Niklas Heidloff (OpenNTF) openntf.org/internal/home.nsf/…Simon O'Doherty

2 Answers

7
votes

I would suggest using the OSGi Tasklet service, a.k.a. DOTS. This approach allows Java tasks to be scheduled or bound to events, just like agents, but perform significantly more efficiently than agents. Perhaps most pertinent to your need is the additional ability to trigger DOTS tasks via the console, which would allow your XPages code to start the Java code merely by issuing a remote console command via the session object.

In addition, check out the technique used in the XSP Starter Kit to provide a serverScope variable. If your code is running in a DOTS task (or even an agent), it's running in a different Java application, so it can't talk directly to the standard scope variables. The serverScope approach would theoretically allow you to store objects that can be accessed from both the XPage and the triggered task. This could aid in using Mark's technique, as mentioned above by Per, to convey progress to the user while the task is running: you'd just be storing the progress information in serverScope instead of sessionScope.

0
votes

A solution would be to have an agent react on saving new documents in the database instead of kicking of the agent in your application and use threads ( because threads can be very dangerous and could easily kill your http task )

Another thing you could look into is why the code that you want to execute is taking 2 minutes to complete. What is the code for? Doing things in other databases or connect to other non notes resources?