Вопрос

Я новичок в EJB и полноценных серверах приложений, таких как JBoss, поскольку большую часть своей карьеры я писал и работал с автономными Java-приложениями специального назначения, ограниченно используя Java EE.Мне интересно, как лучше всего адаптировать часто используемый шаблон проектирования к EJB3 и JBoss:статический шаблон фабрики.На самом деле это пункт №1 в книге Джошуа Блоха «Эффективный Java» (2-е издание).

В настоящее время я работаю со следующей фабрикой:

public class CredentialsProcessorFactory {
    private static final Log log = LogFactory.getLog(CredentialsProcessorFactory.class);
    private static Map<CredentialsType, CredentialsProcessor> PROCESSORS = 
        new HashMap<CredentialsType, CredentialsProcessor>();

    static {
        PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
    }

    private CredentialsProcessorFactory() {}

    public static CredentialsProcessor getProcessor(CredentialsType type) {
       CredentialsProcessor p = PROCESSORS.get(type);
       if(p == null)
           throw new IllegalArgumentException("No CredentialsProcessor registered for type " + type.toString());
       return p;
}

Однако в классах реализации CredentialsProcessor мне требуются внедренные ресурсы, такие как PersistenceContext, поэтому я сделал CredentialsProcessor интерфейс а @Local интерфейс, и каждый из объектов отмечен значком @Stateless.Теперь я могу найти их в JNDI и использовать внедренные ресурсы.

Но теперь у меня отключено, потому что я больше не пользуюсь фабрикой.Первой моей мыслью было поменять getProcessor(CredentialsType) метод для выполнения поиска JNDI и возврата необходимого экземпляра SLSB, но затем мне нужно настроить и передать правильное квалифицированное имя JNDI.Прежде чем пойти по этому пути, я хотел бы провести больше исследований общепринятых практик.

Как этот шаблон проектирования обрабатывается в EJB3/Java EE?

Это было полезно?

Решение

Когда вы начинаете играть с фабриками и «настоящим» Java-кодом POJO, вам в основном нужно полагаться на JNDI.

Внедрение зависимостей работает только с управляемыми компонентами EJB-сервера, а это в основном сервлеты и EJB.

Когда вы говорите об общем Java-коде, который хочет ссылаться на EJB, ему необходимо самостоятельно искать ресурсы через JNDI.

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

Это просто общее правило.

Теперь, для вашего конкретного случая, подумайте об этом.

У вас есть:

static {
    PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
}

Это ничем не отличается от:

static {
    PROCESSORS.put(CredentialsType.CSV, "java:comp/env/ejb/CSVCredentialProcessorSessionBean");
}

Затем в вашем коде getProcessor():

Context c = new InitialContext();
return (CredentialsProcessor) c.lookup(PROCESSORS.get(type));

Видите ли, по сути, код идентичен, и ваш заводской интерфейс для клиентов одинаков.

Вам нужно «жестко запрограммировать» ключ поиска JNDI, но теперь вы все равно «жестко закодируете» имена классов, так чем же это отличается?

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

В Java EE 6 гарантированы переносимые имена.Если вы сегодня не портируете контейнеры, то вообще не беспокойтесь по этому поводу.

Так что, по сути, это вообще не разрыв связи.

Другие советы

При использовании EJB3 обычно не требуется выполнять поиск JNDI.EJB3 поддерживает внедрение зависимости EJB и некоторых других типов ресурсов.Если ваш атрибут bean-компонента помечен с помощью @EJB, зависимость будет автоматически внедрена контейнером.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top