If you want to see the timers of one specific Bean you have to have the dumpTimers() method in that Bean.
Each Bean will have its own timers.
Is there a way for the bean to have a method that would pass the timers to another program?
public Collection<Timer> getAllTimers()
** I tried the above but I'm getting serializable error.
Have you tried query/parse the underlying timer storage? Of course its format or structure may change any time but that seems to be the quickest way to get what you want.
in EJB 3.2 there will be a TimerService.getAllTimers() to return all timers for the current ejb jar, but still won't give you all timers in the server instance.
In your code above, you could return a string representation t.getInfo(), or TimerHandler. I suppose you only need timers for view only purpose, without invoking any timer operations on them.
A Timer is a server internal Object that should not be given to an external program, also it is not usable for this. This is the reason for Timer not implement Serializable.
If you only want to have an overview you might collect a string representation with some properties (i.e. next timeout, persistent, recurring, owner, ...).
Until EJB3.2 you have to implement a Bean wich calls all known timers in your app, starting with 3.2 you might use the approach Cheng mentionend.
Thanks Cheng and Wolf.
Your suggestions have been a big help.
As an FYI - We do have plans to make the EJB timers more "manageable" in AS 7.2.x version.
That sounds even better Jaikiran.
I do have a couple of more questions regarding timers.
1. If the date and time defined in a scheduleExpression of a Timer are in the past will they
be processed once the application server is started?
2. If the Timer is not explicitly canceled with the .cancel() method will the Timer continually
try and get processed if the date and time are in the past?
Thanks again for all of your help.
This Is what the EJB spec says:
Timers are persistent objects (unless explicitly created as non-persistent timers). In the event of a container crash or container shutdown, any single-event persistent timers that have expired during the intervening time before container restart must cause the corresponding timeout callback method to be invoked upon restart. Any interval persistent timers or schedule based persistent timers that have expired during the intervening time must cause the corresponding timeout callback method to be invoked at least once upon restart.
If yo add the timer via API persistent will call the timeout-method for each missing event, a non-persistent timer does not exist after server (re)start.
If you have a @Schedule annotated one a persistent timer behaviour is the same as above, a non-persistent will call the timeout-method for the next schedule, missed times are lost.
Thanks again Jaikiran and Wolf.