Well, to be pedantic, a ContextListener is not a Servlet, but it does go in a web app.
Unfortunately, you're kind of stuck then.
1) EJB 3.0 doesn't present any application level life cycle events, outside of a web app. There are component life cycle events (like for a session bean), but those aren't tied to actual application startup or shutdown.
2) Glassfish doesn't offer any obvious extensions that offer this either. Glassfish DOES offer Lifecycle Listeners, but they're tied to the actual SERVER, not any specific application there in.
3) The problem you're talking about is tied directly to deployment of the EJB that needs the timer. Timers are saved over server restarts, but they are destroyed when the application is undeployed, so what you really want is something to fire when the application is deployed. (So a server lifecycle doens't really help you here either.)
4) There MIGHT be some notification or other message broadcast throughout the underlying JMX/AMX environment whenever an application is deployed that you might be able to tap in to in order to tickle the server. Install a custom MBean, subsribe to a notification. But, that seems like a lot of work to. Just saying it can be done.
If you wanted, you could add a simple call to a popular Session Beans life cycle. The @PostConstuct annotation can be use to flag a method, and this method will be called each time a Session Bean is constructed. Since Session Beans are stateless, they're pooled, so this method will be called rarely, but it will certainly be called more than once. It can quickly check for the timer's existence and move forward from there.
The key here is that it be a popular SB. Because if you deploy the application to a server, and it just sits idle, basically nothing will happen. But as soon as your popular SB gets called, it's PostConstruct method will be called ensuring the timer is installed. Basically, SOMETHING is going to have to "tickle" the server through this popular SB before the timer works at all, but it only has to happen once (ideally) in the life time of the actual application deployment.
So, basically, this just ensures the timer is installed through common use of the server.
But if you deploy the app and just let it sit, you're pretty much dead in the water.
The ContextListener in a WAR is really the "best" solution. Mind, it can be the only thing IN the WAR. I don't even know if you have to have a HTTP listener configured to deploy a WAR (I would imagine, but I don't know). You can always bind it to the admin consoles http listener if you're concerned with burning a socket on the server (assuming you enable the admin console).
However, you would need to bundle the WAR with your EJB so they're part of the same "application" and thus start at the same time (otherwise the container might deploy the WAR before the EJB). Of course, you can probably just deploy the WAR AFTER the EJB. Pretty sure the container is deterministic in it's application startup order, even if that order isn't specifically defined or guaranteed. Then it can just be a WAR making a Remote EJB call.
Oh, EJB 3.1 solves these problem, it offers both the Scheduling facility, and a Startup annotation for a Singleton (as well as Singleton beans, golly everything is in here!). Doing this in EJB 3.1 would be to use either Schedule or a Startup Singleton. I know you can't use it, just FYI.
Curious in what plan you decide to do.
[Message sent by forum member 'whartung']
http://forums.java.net/jive/thread.jspa?messageID=469451