Что такое InitialContext в Java EE вместо mappedName?

Question

Я не понимаю, когда кто-то будет использовать (new InitialContext()).lookup(....) вместо

@Stateless(mappedName="A1Global")
public class A1 implements A { ... }

@EJB(mappedName="A1Global")
private A a;

у последнего подхода с mappedName есть какие-либо недостатки? Я также заметил, что имя JNDI может быть специфичным для поставщика, сложным и излишне длинным.

Answer 1

Захват EJB с помощью JNDI может быть полезен в классах, которые не управляются контейнером внедрения зависимостей и, следовательно, где @EJB просто не сработает. Однако это редкие случаи, которые обычно вызваны ошибкой или недосмотром спецификации, связанной с клиентской средой, в которой вы хотите использовать @EJBи должны сообщаться, обсуждаться и решаться в более новых версиях этой клиентской инфраструктуры, так что в конечном итоге можно будет просто использовать @EJB,

Например, JSF, инфраструктура MVC Java EE, поддерживает пользовательские преобразователи и валидаторы. Однако из-за недосмотра @EJB не поддерживается в пользовательском JSF Converter или же Validator в то время как они могут время от времени вызывать вызов бизнес-службы. Это было решено в JSF 2.3, но до этого времени одним из обходных путей было захватить EJB с помощью JNDI - хотя это было довольно неуклюже, но были и более простые обходные пути, см. Также Как ввести @EJB, @PersistenceContext, @Inject, @Autowired, и т.д. в @FacesConverter?

Та же самая история продолжается для Bean Validation, платформы проверки Java EE. @EJB не было поддержано в кастоме ConstraintValidator до версии 1.1. См. Также проверку JSF 2.0 в методе actionListener или action.

Имя JNDI в случае EJB не зависит от поставщика. По крайней мере, это не так, как указано в Java EE. Однако это зависит от способа упаковки EJB, а также от того, где находится EJB-клиент в приложении. Ответ на этот связанный с этим вопрос объясняет, как составляется имя JNDI и какое из них следует использовать в зависимости от расположения клиента EJB: программно вводить компонент EJB из управляемого компонента JSF.

В двух словах, если вы можете использовать @EJB, тогда непременно воспользуйтесь им. Если вы не можете, то сначала исследуйте, правильно ли вы поступаете. Иногда люди пытаются захватить EJB в месте, где это абсолютно не имеет смысла. Если вы можете подтвердить, что у вас не единственные проблемы с использованием @EJB чтобы достичь желаемого функционального требования, сообщите о проблеме клиентской платформе. Большие шансы, что они добавят @EJB поддержка в намеченном месте.

Тем не менее, если ваша среда поддерживает CDI, вам необходимо знать, что в эти дни рекомендуется выполнить миграцию. @EJB в @Inject, В Java EE 6/7 это будет прекрасно работать, если ожидать одного углового случая (циклическое внедрение EJB в себя). Целью CDI является объединение всех различных механизмов внедрения зависимостей в рамках Java EE в единый API. JSF, например, уже планирует отказаться от своей @ManagedBean/@ManagedProperty в пользу @Named/@Inject в будущей версии Java EE. См. Также ao Backing beans (@ManagedBean) или CDI Beans (@Named)? То же самое может случиться для @EJB в пользу @Inject,