Well, there's always java.util.Timer.
But it's "frowned upon" to create Threads within the container, notably without the container "knowing about it", as Threads are one of the resource the container is designed to manage.
That doesn't mean it can't be done, just, rather, it shouldn't be done.
That said, the other problem you have within JEE is that if you were to do this, using pretty much ANY mechanism, your utility will need to have it's life cycle tied to the applications life cycle.
The only (easy) way to do that in JEE is to tie it to a ServletContextListener, or a simple Servlet, since these modules have their lifecycles tied to the container itself. (EJBs have lifecycles, but they're tied to the component, not the container.)
You have to watch the lifecycle so that you can cleanly stop your timers, threads, etc. when your application gets shutdown. java.util.Timer, for example, doesn't "daemoize" it's threads, so the container won't shut down if you don't cancel the timer. Well, the JVM won't exit.
Java Connector Resources can use threads in JEE, and they have a lifecycle tied to the container, so that may be an option, but, of course, it's tied to JEE.
See, that's the rub. In J2SE, you can do whatever you want, as you're responsible for the entire application and its infrastructure. In JEE, you simply don't have that freedom because your application is working within a managed environment. And that "bureaucracy" places limitations on its client.
The best way to do this I think that will work for JEE is to place your timer facility in its own JAR file, and put that JAR file in the containers class path (i.e. don't include it in the WAR/EAR deployed within the container). Then you can have your classes manage their own singletons and resources. You will most likely not have any reasonable lifecycle unless you implement that yourself within your applications (perhaps tied to the container lifecycle).
Your implementation could be as crude as a singleton that lazily creates a daemon thread to do the work and simply persists until the JVM is exited, just be aware that you may be managing two or more completely different and unrelated clients (what if you have 2 distinct WARs deployed in the same container asking for services from your utility, how to you segregate them?).
The structure will work in most any modern container, and it should work in any J2SE app as well. Being loaded from a library, you will also most likely have your code available to everyone in the conatiner, but, as a corollary, your utility most likely will NOT have access to client code. So, don't expect to be able to instantiate client classes from your utility, though you can certainly call callback methods on passed objects.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=321765