Официального API для этого в EJB 3.1 просто нет.
Если вы используете только аннотации и / или интерфейсы для маркировки метода тайм-аута, вы можете выполнить обход всех классов в пути классов и проверить, присутствуют ли эти аннотации или интерфейс.Это по крайней мере даст вам бины, которые теоретически могут иметь таймеры, связанные с ними.
К сожалению, это все равно не даст вам фактические таймеры для этих бинов.В EJB 3.1 информация о времени может быть запрошена только из контекста сеанса, который, как вы уже знаете, является приватным для каждого компонента.Это означает, что только сам bean-компонент может видеть, какие таймеры у него есть.
В качестве альтернативы тому, что предлагает Nayan, вы можете позволить своим bean-компонентам реализовать метод, который дает вам эту информацию.Затем вы можете пометить этот метод либо интерфейсом, либо пользовательской аннотацией.
При общесистемном циклическом просмотре всех классов таймеров вы сначала пытаетесь обнаружить все компоненты, которые могут иметь связанные с ними таймеры, и тезатем попытайтесь найти, есть ли у них необходимая аннотация или интерфейс.Если у них нет этой последней вещи, вы можете записать предупреждение.Преимущество этого метода в том, что менее вероятно, что таймеры проскользнут сквозь трещины.
Еще один метод, но очень хрупкий, заключается во взломе любой частной структуры, которую содержит контейнер для хранения информации таймера.Для постоянных таймеров есть, по крайней мере, постоянное хранилище, которое вы можете проверить, и где-то в контейнере должна быть структура, к которой вы стремитесь.Он должен быть там, так как сам контейнер должен знать об этом.Часто контейнер имеет некоторый закрытый API, чтобы добраться до этого, и вы можете взломать его с помощью рефлексивных приемов.
Также может быть, что контейнеры предлагают собственный API для этого.Например, в Java EE 5 невозможно выполнить программный вход в систему в контейнере сервлетов, но JBoss AS имеет собственный API, который позволяет вам делать именно это.