EJB вызывает EJB в WebLogic и OpenEJB - PullRequest
Новая
       76

EJB вызывает EJB в WebLogic и OpenEJB

2 голосов
/ 20 сентября 2011

Я хочу написать приложение, которое имеет 2 EJB.Это приложение может работать как в OpenEJB, так и в WebLogic 10.3.Оба EJB являются EJB 3.0.

Я знаю, как реализовать как в OpenEJB, так и в WebLogic, но проблема в том, что я хочу использовать один и тот же код для развертывания в обеих средах.Я думаю, что проблема заключается в том, как выполнить поиск JNDI, потому что Context.INITIAL_CONTEXT_FACTORY в WebLogic имеет вид weblogic.jndi.WLInitialContextFactory, а OpenEJB - нет.

Текущая идея заключается в том, что 1-й EJB-объект использует локатор служб для поиска 2-го EJB исервисный локатор будет читать разные INI в 2 средах.Есть ли другие предложения?Есть ли решение, в котором я могу просто использовать аннотацию, не нужно использовать внешние файлы INI.

2 EJB-компонента живут в одном контейнере, но возможно, что в будущем он будет перемещен в другой контейнер.

Обновление от 2011/10/06

По предложению Дэвида я внес некоторые изменения.Код является POJO, а не кодом JUnit.Он не использует @LocalClient и initialContext.bind («inject», this);(Я поместил код 2 в свой код JUnit)

  1. Положите ресурсы \ META-INF \ application-client.xml (только содержат)

  2. Поместить ресурсы \ jndi.properties 

    jdbc/OrderDB = new://Resource?type=DataSource
jdbc/OrderDB.JdbcDriver = oracle.jdbc.OracleDriver
jdbc/OrderDB.JdbcUrl = jdbc:oracle:thin:@*.*.*.*:1521:test
jdbc/OrderDB.JtaManaged = false
jdbc/OrderDB.UserName = test
jdbc/OrderDB.Password = test

  3. Код поиска 

    InitialContext ctx= new InitialContext();
ctx.lookup("jdbc/" + name);

Ниже приведен журнал, OpenEJB создает JNDI длябаза данных.Я также использую режим отладки Eclipse, чтобы увидеть содержимое "ctx" и найти "jdbc / OrderDB" в MyProps 

INFO - Configuring Service(id=jdbc/OrderDB, type=Resource, provider-id=Default JDBC Database)

Но, наконец, я все еще не могу найти его.Я также пытаюсь использовать ctx.lookup (name), ctx.lookup ("java: comp / env / jdbc /" + name), и результат тот же. 

javax.naming.NameNotFoundException: Name "jdbc/OrderDB" not found.

Обновление 2011/10/ 12

Основываясь на комментариях Дэвида, до Java EE6, я думаю, что единственное решение - использовать локатор служб и некоторую конфигурацию для использования различных JNDI между WebLogic и OpenEJB.Ниже приводится результат теста.

БД: WebLogic: OrderDB, OpenEJB: openejb: Resource / jdbc / OrderDB

Менеджер транзакций: WebLogic: javax.transaction.TransactionManager, OpenEJB: java: comp / TransactionManager

EJB : оба они просто ищут имя EJB без префикса

Ответы [ 3 ]

2 голосов
/ 09 октября 2011

Вопрос в обновлении - это совсем другой вопрос, поэтому публикуем другой ответ.

Нет глобального JNDI до Java EE 6

Длинный и короткий от него доJava EE 6, нет глобального JNDI.Так что в буквальном смысле слова вопрос «что такое имя JNDI x» является неопровержимым вопросом.Каждый EJB имеет свое собственное пространство имен JNDI, а «POJO» вообще не имеет пространства имен, они используют пространство имен JNDI независимо от того, что EJB вызвало его.Таким образом, чтобы «java: comp / env / myDataSource» выглядел как можно более глобальным, вы должны объявить эту ссылку для каждого отдельного EJB-компонента в приложении.

Объем работ по настройке, который это создает для пользователей, весьма разрушителен,В Java EE 6 наконец-то есть Global JNDI и три новых стандартных пространства имен, java:module, java:app и java:global.Любая функциональность Global JNDI, существующая до Java EE 6, зависит от поставщика и является непереносимой.

Специфичным для поставщика и непереносимым способом поиска Global JNDI в OpenEJB для заданного имени будет поиск.openejb:Resource/jdbc/OrderDB

Называя вещи своими именами

В OpenEJB мы намеренно не поддерживаем нестандартные поиски, такие как jdbc/OrderDB или java:jdbc/OrderDB, как это делают некоторые поставщики.Требуемый префикс для глобальных имен в OpenEJB: openejb:.

JNDI является сложным и достаточно запутанным, а непереносимые имена выглядят так, будто переносимые имена не приносят пользы пользователям.Если определенный стиль именования непереносим и собирается создать привязку к поставщику, он должен выглядеть следующим образом.Таким образом, с префиксом openejb: вы можете получить доступ ко всему, что вам нужно в глобальном масштабе, но по крайней мере ясно, что то, что вы делаете, не является переносимым и не следует ожидать, что оно будет работать на других платформах без некоторой модификации.

1 голос
/ 27 сентября 2011

Обратите внимание, что существует стандартный файл jndi.properties, который можно использовать для вывода 100% конфигурации, обычно передаваемой в качестве свойств IntitialContext

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

Вам просто нужно убедиться, что файл jndi.properties находится на пути к классам клиента в корне (то есть не в каталоге META-INF). IntialContext найдет его и загрузит. Любые свойства, переданные в конструктор IntialContext, просто переопределяют свойства, переданные через jndi.properties

На стороне OpenEJB должна быть возможность изменить формат имени JNDI , чтобы он соответствовал формату WebLogic. Если нет, дайте мне знать, и мы можем добавить любые недостающие метаданные в форматтер, чтобы можно было точно их сопоставить.

0 голосов
/ 20 сентября 2011

Разве вы не можете просто использовать контекст по умолчанию? Тогда вам не нужно указывать конкретную реализацию, и вы можете выполнить поиск через стандартную ссылку.

В противном случае, я думаю, у вас есть какой-то файл свойств для определения деталей контекста во время выполнения.

...