Hi folks,

I'm looking for some kind of design pattern that can help solve the following problem:

How can you thread a call to an EJB in a Swing application? in a generic fashion, without using reflection to discover EJB services?

I realize threading a Swing application should be avoided, but we have no choice in this case.

Basically, our problem is this:
We have many internal frames in a Swing program.
If an internal frame invokes an EJB method that will take a long period of time - we don't want the operation to lock
up any part of the application.

The question boils down to:

How can you thread a call to an EJB - keeping in mind that
there are many EJB's. We were originally using reflection to solve the problem, but to be blunt the reflection API is just too slow.

Any comments/suggestions would be greatly appreciated.

Cheers,
Glenn Hemming

Is it generic enough to provide a "functional object," similar to the AWT/Swing event handler?

Let the client of the threading utility define the call to the EJB in a "run()" method, which is part of an anonymous implementer of a callback interface defined by the utility. The threading service then calls the run() method at an appropriate point, which could return a result back to the client in a number of ways.

This way, you don't have to use reflection - you just encapsulate the action to be threaded.