Possible answer: Not at all?

Why on earth would you want a EJB business method to wait for something?
 Apart from the well known fact, that business methods always take too
long to execute, there is no sensible thing to wait for without
violating the EJB principles.
Maybe tell us *what* you plan to do....

Greetings
Andreas

Try a google search on "j2ee scheduler".  Many implementations appear at
the top.  The J2EE 1.4 timer service is a standardized spec for this
concept that is built-in as of that version.  But they exist as separate
products compatible with earlier versions.

John

We've used Quartz with weblogic, with success.  

But I'd be looking for a message driven approach, so that instead of the
business object doing the timing, have the timing be handled some way
other than just a delay in the EJB.  JMS has possibilities for doing
synchronous messages.

That said, you can of course do it by brute force, spec or no spec.
Thread.sleep, or blocking IO, aren't *proper* in an EJB, but they do
actually *work* for the most part.  But when you go down that road,
you're making assumptions about the object's lifecycle, doing things
that will be even more of a pain when your shop finally migrates to
JBoss, and who knows what will happen in production, or if you want to
introduce clustering, or if you end up looking for bugs that are related
to synchronous behavior?