2011-01-07 4 views
3

Я работаю над большим приложением Java EE 6, которое развернуто на JBoss 6 Final. Мои текущие задачи включают использование @Inject последовательно, а не @EJB, но я сталкиваюсь с некоторыми проблемами с некоторыми типами bean-компонентов, в частности с bean-компонентами и фасолью @MessageDriven с методами @Scheduled.Как работает инъекция CDI в MDB и фасоли @Scheduled?

Что происходит, если мне не повезло с выбором времени (для @Schedule) или если в процессе запуска есть сообщения в очередях MDB, создание экземпляров будет проиграно, потому что вложенные ресурсы (которые сами EJB) пока не связаны.

Поскольку я использую @Inject, я предполагаю, что контейнер EJB считает мои бобы готовыми, так как сам контейнер не заботится о @Inject; он, вероятно, просто предполагает, что, поскольку нет инъекций @EJB, бобы готовы к использованию. Введенные прокси-серверы CDI будут терпеть неудачу, потому что ресурсы для инъекции еще не связаны.

Крошечный пример:

@Stateless 
@LocalBean 
public class MySupportingBean { 

    public void doSomething() { 
     ... 
    } 
} 

@Singleton 
public class MyScheduledBean { 

    @Inject 
    private MySupportingBean supportingBean; 

    @Schedule(second = "*/1", hour = "*", minute = "*", persistent = false) 
    public void onTimeout() { 
     supportingBean.doSomething(); 
    } 
} 

В приведенном выше примере, вероятно, не выходит из строя часто, потому что есть только два зерно, но проект я работаю над связывает много EJBs, который будет усиливать эту проблему. Но это может потерпеть неудачу, потому что нет гарантии, что MySupportingBean привязан первым, и если onTimeout вызывается до того, как MySupportingBean привязан, тогда создание экземпляра MyScheduledBean завершится неудачно. Если бы я использовал @EJB вместо этого, MyScheduledBean не был бы связан, пока зависимость от MySupportingBean не была удовлетворена.

Обратите внимание, что пример не выйдет из строя в самом onTimeout, но когда CDI пытается ввести MySupportingBean.

Я читал много сообщений на разных форумах, где многие люди утверждают, что @Inject всегда лучше. Как правило, я согласен, но как они обрабатывают @Schedule или @MessageDriven в сочетании с @Inject? По моему опыту, дело доходит до того, что бобы будут работать или нет в этих случаях, и бобы будут терпеть неудачу произвольно, в зависимости от того, в каком порядке развертываются EJB, и когда вызывается @Schedule или onMessage.

ответ

0

Это может помочь явно определить зависимости, используя фирменную аннотацию JBoss @Depends или с помощью файла jboss.xml.

Смотрите это за несколько похожий вопрос: How to order deployment of EJBs and JMS queue config in JBoss 5?

+0

Я считал, что возможность, но быть сервером приложений агностик вид важно; по политическим причинам намного выше меня, мы, скорее всего, переключимся на другой сервер приложений в ближайшем будущем. Кроме того, должны ли мы действительно зависеть от проприетарных аннотаций, чтобы сделать общую работу рамок, как и ожидалось? –

+1

Вы правы, мы не должны. Но когда приходит толчок, нужно иногда практическое решение. При использовании xml-файла вы можете включить похожие файлы для всех других крупных серверов (есть ли на этих других серверах даже эта проблема?). Я согласен, что это уродливое решение и надеюсь, что кто-то другой сможет предоставить стандартный ответ. –

+0

Я думаю, вы правы. Это не тот ответ, на который я надеялся, но, конечно, мы должны прагматично. Из двух зол, я думаю, что XML-файл является меньшим - по крайней мере, таким образом я не буду вводить специфические аннотации JBoss в исходном коде. И у нас уже есть дескрипторы развертывания для JBoss, которые, конечно же, должны быть заменены новым сервером приложений. Скорее всего, мы перейдем к WebSphere в ближайшем будущем, но мы еще не начали его тестировать. Будет интересно посмотреть, похоже ли поведение WebSphere. –

Смежные вопросы