Проблема поиска EJB - PullRequest
Новая
       4

Проблема поиска EJB

0 голосов
/ 02 августа 2011

У меня есть настройка кластера Glassfish v2.1.1.Я развернул EAR-файл, состоящий из одного bean-компонента без сохранения состояния, на отдельном сервере.Он имеет порт IIOP 3752.

Мое клиентское приложение, которое будет взаимодействовать с этим компонентом, развернуто в кластере.Когда я ищу имя бина, я получаю исключение NameNotFoundException.Код выглядит следующим образом: 

Properties props = new Properties();

props.setProperty("java.naming.factory.initial",    "com.sun.enterprise.naming.SerialInitContextFactory");

props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");

props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");


if (logger.isDebugEnabled()) {

  logger.debug("Looking for bean from location : " + PropertiesService.instance().getSchedulerOrbHost() + ":"

                + PropertiesService.instance().getSchedulerOrbPort());

}


props.setProperty("org.omg.CORBA.ORBInitialHost",     PropertiesService.instance().getSchedulerOrbHost());

props.setProperty("org.omg.CORBA.ORBInitialPort",     PropertiesService.instance().getSchedulerOrbPort());


InitialContext context = null;


try {

context = new InitialContext(props);

} catch (NamingException e) {

e.printStackTrace();

}

String beanName = "test.OperationControllerRemote";

OperationControllerRemote remote = (OperationControllerRemote) context.lookup(beanName);

Обратите внимание, что я проверил дерево JNDI и имя "test.OperationControllerRemote".

Есть какие-либо мнения, пожалуйста?

1 Ответ

0 голосов
/ 02 августа 2011

Вот способы заставить его работать с кластером GF 2.1.1 и клиентом Swing.В настоящее время я использую автономный вариант из-за скорости запуска клиента, но ACC может работать на вас.

Автономный

То, как вы это делаете, считается автономным.

http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

http://blogs.oracle.com/dadelhardt/entry/standalone_iiop_clients_with_glassfish

ACC

Другим способом решения этой проблемы является запуск клиента с ACC.Это означает упаковку клиентского кода в ухо в качестве Application Client и либо запуск с использованием метода JNLP, либо ручную установку связанного ACC (на самом деле мини-стеклянная рыбка) на клиентских компьютерах.В GF 2.1 любой способ работает нормально, но оба довольно толстые, и метод JNLP может увеличить время запуска.Предположительно в GF 3.1 они переработали ACC, и он запускается быстрее.Что-то, что может быть неочевидным, это то, что с помощью ACC вы получаете список серверов в кластере, предоставленный автоматически при запуске клиента.

http://blogs.oracle.com/theaquarium/entry/java_ee_clients_with_or

http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beakv.html#scrolltoc

http://download.oracle.com/docs/cd/E18930_01/html/821-2418/gkusn.html

Поиск

Любой из вышеперечисленных способов обеспечивает отработку отказа RMI / CORBA и балансировку нагрузки для клиента.

В любом случае, если у вас есть правильные зависимости от вашегоclasspath и системный набор свойств com.sun.appserv.iiop.endpoints (например, node1: 33700, node2: 33701), вам потребуется только InitialContext без аргументов, потому что материал Glassfish автоматически регистрирует их свойства подключения и т. д., как описано в первой ссылке: 

new InitialContext()

И поиск будет работать.Для моих удаленных сессионных компонентов (EJB 3.0) я обычно делаю это следующим образом: 

@Stateless(mappedName="FooBean")
public class FooBean implements FooBeanRemote {}

@Remote
public interface FooBeanRemote {}

, затем в коде клиента: 

FooBeanRemote foo = (FooBeanRemote) ctx.lookup("FooBean");
...