@EJB аннотация - какая обработка ошибок подходит? - PullRequest
Новая
       4

@EJB аннотация - какая обработка ошибок подходит?

3 голосов
/ 20 сентября 2009

Аннотация @EJB может использоваться в «управляемых клиентах» для доступа к EJB.

Эту аннотацию можно поместить в класс сервлета, объявив переменную-член. 

public class MyServlet extends HttpServlet {
     @EJB
     private MyWorkerInterface theWorker;
}

Эта аннотация @EJB расширена до поисков JNDI, которые (я предполагаю) выполняются при инициализации сервлета. Эти поиски JNDI могут завершиться неудачей: поставщик EJB может изменить свои аннотации, указав конкретные имена JNDI, тогда моей ссылке @EJB потребуется указать имя JNDI не по умолчанию, иначе поиск не удастся.

Также я предполагаю, что, поскольку EJB может быть удаленным, существует вероятность временных, сетевых сбоев и ошибок отказов сервера.

Моя мысль: при использовании theWorker я должен проверить его действительность. 

  if ( theWorker == null ) {
      // ... etc.

Мои вопросы:

1.) Нужны ли такие нулевые проверки?

2.) Если они равны и , то значения NULL могут быть вызваны временной ошибкой, такой как временный сбой удаленного сервера, возможно ли какое-либо восстановление? Сервлет теперь инициализирован. Мне действительно нужно перезапустить мой сервлет для восстановления? Конечно, нет?

3.) Предварительная мысль: для предпочтения использованию @EJB может потребоваться явный, ленивый код поиска JNDI. Комментарии?

1 Ответ

3 голосов
/ 20 сентября 2009

Извините, что не дал никаких ссылок на спецификации, я говорю только из предыдущего опыта с JBoss.

1) Нет, если контейнер не допустил ошибку.
2) Не имеет значения, ваш экземпляр будет прокси для удаленной службы, реализующей удаленный интерфейс. Поэтому инъекция всегда будет успешной. Ошибка возникнет при вызове методов прокси, поэтому вам нужно быть готовым к обработке этих ошибок при использовании удаленного интерфейса. Именно для этого и предназначалось RemoteException, все ошибки должны быть заключены в RemoteException, чтобы вы могли отследить, если что-то пойдет не так. Если вы позволите ему распространяться, tx будет откатан, что является нормальным значением по умолчанию, если вы манипулируете только ресурсами с поддержкой tx.
3) Обычно это требуется только в том случае, если для поиска JNDI требуются разные начальные свойства контекста, но в этих случаях я лично использовал бы механизм DI и другую аннотацию (например, @ EJBFromHost2). Использование явных поисков JNDI становится очень запутанным, особенно если вы позже захотите перейти на другую реализацию или настройки JNDI (например, если вы хотите кластеризовать свое приложение).

...