How to get all EJB timers?

Question

In EJB 3.1 I can get all timers for a specific bean using TimerService#getTimers() on the TimerService instance obtained for that bean.

What I actually need however

Answer 1

EJB 3.2 has a method called "getAllTimers()".

https://docs.oracle.com/javaee/7/api/javax/ejb/TimerService.html#getAllTimers--

Description: Returns all active timers associated with the beans in the same module in which the caller bean is packaged. These include both the programmatically-created timers and the automatically-created timers.

Answer 2

Below is the sample code fragment for fetching information of all the existing timers of the system.

//---

private void viewSystemTimers(){

        Collection<Timer> allTimers = sessionContext.getTimerService().getTimers();

        Iterator<Timer> iterator = allTimers.iterator();

        while (iterator.hasNext()) {

            Timer timer = (Timer) iterator.next();

            System.out.println("SYSTEM TIMER : "+timer.getInfo());
        }
    }

//---

Answer 3

You can only see timers of your own class. With the EJB Scheduler you can't list all timers of your application.

@Resource
private TimerService timerService;

for (Timer timer : timerService.getTimers()) {
    // do anything
}

With Quartz you can via Scheduler.getJobNames/triggerNames for all jobs/triggers of you application.

Answer 4

There simply is no official API for this in EJB 3.1.

If you're only using annotations and/or interfaces to mark your timeout method, you could do a run-time walk over all classes on the class path and check if this annotation or interface is present. This will at least give you the beans which theoretically can have timers associated with them.

Unfortunately, this still won't give you the actual timers for those beans. In EJB 3.1, the time information can only be requested from the session context, which as you already seem to know is private for each bean. This means that only the bean itself can see what timers it has.

As an alternative to what Nayan is suggesting, you could let your beans implement a method that gives you this info. You can then mark this method with either an interface or a custom annotation.

In your system-wide sweep over all timer classes you first try to discover all beans that can have timers associated with them, and of those you then try to find whether they have the required annotation or interface. If they don't have this latter thing, you can log a warning. The advantage of this method is that it's less likely that timers slip through the cracks.

Yet another method, but a very brittle one, is to hack into whatever private structure the container holds to store the timer information. For persistent timers there is at least the persist store which you can check, and somewhere in the container there must be the structure you're after. It must be there as the container itself has to be aware of this. Often a container has some private API to get to this and you can hack into that via reflective tricks.

It can also be that containers offer a proprietary API for this. E.g. in Java EE 5 it's impossible to do a programmatic login in the Servlet container, but JBoss AS has a proprietary API that allows you to do exactly that.