Как поиск JNDI находит класс java?

Question

У меня есть компонент EJB с удаленным интерфейсом. Он включен в военный файл chapter08-service-1.0.

@Remote 
public interface BookEJBRemote { 
    ... 
} 

После того как я развернуть его на GlassFish я могу назвать это от клиента с помощью

Context ctx = new InitialContext(); 
BookEJBRemote bookEJB = (BookEJBRemote) ctx.lookup("java:global/chapter08-service-1.0/BookEJB!org.agoncal.book.javaee7.chapter08.BookEJBRemote"); 

Он прекрасно работает и вызывает метод. Но я не понимаю, как это найти экземпляр EJB или даже Glassfish? Очевидно, что нет никакой информации о сервере или порту стеклянной рыбы в строке поиска.

Answer 1

Но я не понимаю, как это найти EJB или даже стеклянная рыба instance.instance.

Для того, чтобы получить ссылку на EJB через службу JNDI, в основном вам нужно:

1. подключения к серверу JNDI
2. после подключения, для поиска объекта, используя имя которого он был зарегистрирован.

Для подключения к серверу JNDI вам необходимо предоставить объекту InitialContext несколько информации, такую ​​как ip/port, где прослушивается сервер JNDI. Существуют различные способы инициализации начального контекста, как описано here.

Если вы не предоставите эту информацию, InitialContext попытается выполнить поиск службы в локальном хосте с портом по умолчанию, как было предложено в предыдущем ответе.

Очевидно, что нет никакой информации о сервере или порту стеклянной рыбы в строке поиска.

Из-за описанного выше вы не увидите информацию о URL-адресе или порте как часть параметра имени поиска.

Answer 2

Если вы используете стеклянную рыбу и ваш клиент на том же компьютере, может случиться так, что они оба используют порт JNDI по умолчанию 1099, и поскольку оба находятся на одном компьютере, нет необходимости указывать хост.

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

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

Answer 3

InitialContext не просто выбирает хост по умолчанию (localhost) и номер порта по умолчанию. Эта информация явно задана самой стеклянной фишкой, которая выполняется с использованием технологии Java Webstart.

Вы можете протестировать его самостоятельно: предположим, что клиент вашего приложения развернут в контексте localhost:8080/YourClient. Когда вы переходите к ссылке, файл JNLP загружается и запускается через Webstart. Вы можете вручную сохранить файл, а не открывать его автоматически (например, wget localhost:8080/YourClient на Linux).Вы увидите, что Glassfish инициализирует ваше клиентское приложение с большим количеством параметров, включая свойства JNDI, связанные с:

<property name="java.naming.factory.initial" value="com.sun.enterprise.naming.SerialInitContextFactory"/> 
<property name="java.naming.factory.url.pkgs" value="com.sun.enterprise.naming"/> 
<property name="java.naming.factory.state" value="com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"/> 
<property name="appclient.iiop.defaultHost" value="localhost"/> 
<property name="appclient.iiop.defaultPort" value="${request.appclient.iiop.defaultPort}"/> 
<property name="${appclient.download.host.propertyName}" value="localhost"/> 
<property name="${appclient.user.code.is.signed.propertyName}" value="${appclient.user.code.is.signed}"/> 

Эти свойства не только указаны для вашего удобства, они являются обязательными. Попробуйте запустить клиентское приложение как отдельное приложение (просто запустите основной класс в своей любимой среде IDE): в такой ситуации исходные параметры не будут установлены. Вы заметите, что InitialContext не работает так хорошо без этих свойств.

Короткий ответ на ваш вопрос: InitialContext находит Glassfish и EJB, потому что ваше приложение было запущено со специальными параметрами говорить InitialContext, где искать, как инициализировать необходимые классы и т.д.