Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Вот наиболее распространенные проблемы, с которыми Вы могли бы встретиться, когда Вы пытаетесь выполнить успешно скомпилированную программу, которая использует классы JNDI.
1. Вы получаете NoInitialContextException.
Причина: Вы не определяли который реализация использовать для начального контекста. Определенно, свойство среды Context.INITIAL_CONTEXT_FACTORY не было установлено в имя class фабрики, которая создаст начальный контекст. Или, Вы не делали доступным для программы классы поставщика услуг названный Context.INITIAL_CONTEXT_FACTORY.
Решение: Установите свойство среды Context.INITIAL_CONTEXT_FACTORY в имя class начальной реализации контекста, которую Вы используете. См. раздел
Если свойство было установлено, то удостоверьтесь, что имя class не было введено с опечаткой, и что названный class доступен Вашей программе (или в ее пути к классу или установленный в каталоге jre/lib/ext JRE). Платформа Java включает поставщиков услуг для LDAP, именования COS, DNS, и реестра RMI. Все другие поставщики услуг должны быть установлены и добавлены к среде выполнения.
2. Вы получаете CommunicationException, указывая "на соединение, которому отказывают."
Причина: сервер и порт, идентифицированный свойством среды Context.PROVIDER_URL, не подаются сервером. Возможно, кто-то отключил или выключил машину, на которой работает сервер. Или, возможно Вы вводили с опечаткой имя сервера или номер порта.
Решение: Проверьте, что есть действительно сервер, работающий на том порту, и перезапустите сервер в случае необходимости. Способ, которым Вы выполняете эту проверку, зависит от сервера LDAP, который Вы используете. Обычно, административная консоль или инструмент доступны, который можно использовать, чтобы администрировать сервер. Можно использовать тот инструмент, чтобы проверить состояние сервера.
Причина: сервер не отвечает на LDAP v3 запросы соединения. Некоторые серверы (особенно общедоступные серверы) правильно не отвечают на LDAP v3, игнорируя запросы вместо того, чтобы отклонить их. Кроме того, у некоторых LDAP v3 серверы есть проблемы, обрабатывая управление, которое автоматически отправляет поставщик услуг Sun LDAP, и часто возвращайте специфичный для сервера код отказа.
Решение. Попытайтесь установить свойство "java.naming.ldap.version" to "2" среды. Поставщик услуг LDAP значением по умолчанию пытается соединиться с сервером LDAP, используя LDAP v3; если это перестало работать, то это использует LDAP v2. Если сервер тихо проигнорирует запрос v3, то провайдер предположит что работавший запрос. Чтобы работать вокруг таких серверов, следует явно установить версию протокола, чтобы гарантировать правильное поведение сервером.
Если сервер является v3 сервером, то попытайтесь установить следующее свойство среды прежде, чем создать начальный контекст:
env.put(Context.REFERRAL, "throw");
Это выключит управление, которое провайдер LDAP отправляет автоматически. (Проверьте Учебное руководство JNDI для деталей.)
Причины: Некоторые серверы (особенно общедоступные) не будут отвечать (не даже с отрицательным ответом), если Вы попытаетесь выполнить поиск, который генерировал бы слишком много результатов, или это потребует, чтобы сервер исследовал слишком много записей, чтобы генерировать ответ. Такие серверы пытаются ограничить количество ресурсов, которые они расходуют на основе на запрос.
Или, Вы попытались использовать Уровень защищенных сокетов (SSL) против сервера/порта, который не поддерживает это, и наоборот (то есть, Вы попытались использовать простой сокет, чтобы говорить с портом SSL).
И наконец, сервер или отвечает очень медленно из-за тяжелого груза или не отвечает вообще по некоторым причинам.
Решение: Если Ваша программа зависает, потому что сервер пытается ограничить использование своих ресурсов, то повторите свой запрос, используя запрос, который возвратит единственный результат или только несколько результатов. Это поможет Вам определить, жив ли сервер. Если это, то можно расширить свой начальный запрос и повторно представить это.
Если Ваша программа зависает из-за проблем SSL, то Вы должны узнать, является ли порт портом SSL и затем установил свойство среды соответственно. Если порт является портом SSL, то это свойство должно быть установлено в "ssl". Если это не порт SSL, то это свойство не должно быть установлено.
Если Вы программируете, не зависает ни для одной из вышеупомянутых причин, свойство com.sun.jndi.ldap.read.timeout пригождается, чтобы определить тайм-аут чтения. Значение этого свойства является строковым представлением целого числа, представляющего тайм-аут чтения в миллисекундах для операций LDAP. Если провайдер LDAP не может получить ответ LDAP в пределах того периода, он прерывает попытку чтения. Целое число должно быть больше чем нуль. Целое число, меньше чем или равное, чтобы обнулить средства, никакой тайм-аут чтения не определяется, который эквивалентен ожиданию ответа бесконечно, пока это не получается.
Если это свойство не определяется, значение по умолчанию должно ожидать ответа, пока это не получается.
env.put("com.sun.jndi.ldap.read.timeout", "5000"); заставляет поставщика услуг LDAP прерывать попытку чтения, если сервер не отвечает ответом в течение 5 секунд.
5. Вы получаете NameNotFoundException.
Причины: Когда Вы инициализировали начальный контекст для LDAP, Вы предоставляете корневое отличительное имя. Например, если Вы устанавливаете свойство среды Context.PROVIDER_URL для начального контекста к "ldap://ldapserver:389/o=JNDITutorial" и впоследствии предоставляли имя, такое как "cn=Joe,c=us", тогда полным именем, которое Вы передали к службе LDAP, был "cn=Joe,c=us,o=JNDITutorial". Если бы это было действительно именем, которое Вы предназначали, то следует проверить свой сервер, чтобы удостовериться, что это содержит такую запись.
Кроме того, возврат Сервера каталогов Java Sun эта ошибка, если Вы предоставляете неправильное отличительное имя в целях аутентификации. Например, провайдер LDAP бросит , если Вы установите свойство среды в "cn=Admin, o=Tutorial", и "cn=Admin, o=Tutorial" не является записью на сервере LDAP. Корректная ошибка для Сервера каталогов Java Sun, чтобы возвратиться фактически должна быть чем-то связанным с аутентификацией, а не "называют не найденным."
Решение: Проверьте имя, которое Вы предоставляли, та из записи, существующей на сервере. Можно сделать это, перечисляя родительский контекст записи или используя некоторый другой инструмент, такой как консоль администрирования сервера каталогов.
Вот некоторые проблемы, с которыми Вы могли бы встретиться, пытаясь развернуть апплет, который использует классы JNDI.
Причина: Ваш апплет не был подписан, таким образом, он может соединиться только с машиной, из которой он был загружен. Или, если апплет был подписан, браузер не предоставил, что разрешение апплета соединяется с машиной сервера каталогов.
Решение: Если Вы хотите позволить апплету соединяться с серверами каталогов, работающими на произвольных машинах, то Вы должны подписать и свой апплет и все JAR JNDI, которые будет использовать Ваш апплет. Для получения информации о подписании фляг см.
Причина: Веб-браузеры ограничивают доступ к системным свойствам и бросают SecurityException, если Вы пытаетесь считать их.
Решение: Если Вы должны получить ввод для своего апплета, то попытайтесь использовать апплет params вместо этого.
Причина: Firefox отключает доступ к пакетам java.security. Провайдер LDAP, используемый функциональность обзора сообщения, обеспечил java.security.MessageDigest для реализации CRAM-MD5.
Решение: Используйте Плагин Java.
|
