Интерфейс контекста

public interface Context

Этот интерфейс представляет контекст именования, который состоит из набора связей "имя-объект". Он содержит методы для просмотра и обновления этих связей.

Имена

Каждое имя, переданное в качестве аргумента методу Context, относительно этого контекста. Пустое имя используется для именования самого контекста. Параметр имени никогда не может быть null.

Большинство методов имеют перегруженные версии, одна из которых принимает параметр Name, а другая — String. Эти перегруженные версии эквивалентны в том, что если параметры Name и String представляют одно и то же имя, то перегруженные версии одних и тех же методов ведут себя одинаково. В описаниях методов ниже приводится только одна версия, которая полностью документирована. Вторая версия содержит ссылку на первую: данная документация применима к обеим версиям.

Для систем, поддерживающих федерацию, параметры имени, передаваемые методам Context, являются составными именами. Параметры имени, которые являются экземплярами CompositeName, обрабатываются как составные имена, в то время как параметры имен, которые не являются экземплярами CompositeName, обрабатываются как составные имена (которые могут быть экземплярами CompoundName или других реализаций составных имен). Это позволяет использовать результаты NameParser.parse() в качестве аргументов для методов Context. До JNDI 1.2 все аргументы имени обрабатывались как составные имена.

Кроме того, для систем, поддерживающих федерацию, все имена, возвращаемые в NamingEnumeration методами list() и listBindings(), представляют собой составные имена, представленные в виде строк. См. CompositeName для синтаксиса строк имен.

Для систем, не поддерживающих федерацию, аргументы имен (в формате Name или String) и имена, возвращаемые в NamingEnumeration, могут быть именами в их собственном пространстве имен, а не именами в составном пространстве имен, по усмотрению поставщика услуг.

Исключения

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

Одновременный доступ

Для экземпляра Context нет гарантии синхронизации против одновременного доступа с помощью нескольких потоков. Потоки, которым нужно получить одновременный доступ к одному экземпляру Context, должны синхронизироваться между собой и обеспечивать необходимую блокировку. Несколько потоков, каждый из которых манипулирует разными экземплярами Context, синхронизироваться не должны. Обратите внимание, что метод lookup, когда ему передано пустое имя, вернет новый экземпляр Context, представляющий тот же контекст именования.

Для целей управления одновременностью операция Context, которая возвращает NamingEnumeration, не считается завершенной, пока перечисление все еще используется или пока любые ссылки, созданные этой операцией, все еще следуют.

Параметры

Параметр Name, переданный любому методу интерфейса Context или одному из его подинтерфейсов, не будет изменен поставщиком услуг. Поставщик услуг может сохранить ссылку на него на протяжении всей операции, включая перечисление результатов метода и обработку любых ссылок, генерируемых. Вызывающая сторона не должна изменять объект в течение этого времени. Объект Name, возвращаемый любым таким методом, принадлежит вызывающей стороне. Вызывающая сторона может впоследствии изменить его; поставщик услуг не может.

Свойства среды

Приложения JNDI нуждаются в способе передачи различных настроек и свойств, которые определяют среду, в которой осуществляется доступ к службам именования и каталогов. Например, контексту может потребоваться указание учетных данных безопасности для доступа к службе. Другой контекст может потребовать предоставления информации о конфигурации сервера. Это называется окружением контекста. Интерфейс Context предоставляет методы для извлечения и обновления этого окружения.

Окружение наследуется от родительского контекста по мере того, как методы контекста переходят от одного контекста к другому. Изменения в окружении одного контекста не влияют напрямую на другие контексты.

Время использования и проверки свойств среды зависит от реализации. Например, некоторые свойства, связанные с безопасностью, используются поставщиками услуг для "входа" в каталог. Этот процесс входа может происходить при создании контекста или при первом вызове метода контекста. Когда и произойдет ли это вообще, зависит от реализации. При добавлении или удалении свойств среды из контекста проверка их корректности также зависит от реализации. Например, проверка некоторых свойств может происходить в момент внесения изменения, или в момент выполнения следующей операции над контекстом, или вообще не происходить.

Любой объект, имеющий ссылку на контекст, может просматривать окружение этого контекста. Чувствительная информация, такая как пароли в открытом тексте, не должна храниться там, если не известно, что реализация ее защищает.

Файлы ресурсов

Чтобы упростить задачу настройки окружения, необходимого приложению JNDI, компоненты приложений и поставщики услуг могут распространяться вместе с файлами ресурсов. Файл ресурсов JNDI — это файл в формате файла свойств (см. java.util.Properties), содержащий список пар "ключ-значение". Ключ — это имя свойства (например, "java.naming.factory.object"), а значение — строка в формате, определенном для этого свойства. Вот пример файла ресурсов JNDI:

java.naming.factory.object=com.sun.jndi.ldap.AttrsToCorba:com.wiz.from.Person java.naming.factory.state=com.sun.jndi.ldap.CorbaToAttrs:com.wiz.from.Person java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory

Библиотека классов JNDI считывает файлы ресурсов и делает значения свойств доступными. Таким образом, файлы ресурсов JNDI следует считать "доступными для чтения всеми", и чувствительная информация, такая как пароли в открытом тексте, не должна храниться в них.

Существует два типа файлов ресурсов JNDI: поставщика и приложения.

Файлы ресурсов поставщика

У каждого поставщика услуг есть необязательный ресурс, который перечисляет свойства, специфичные для этого поставщика. Название этого ресурса:

[префикс/]jndiprovider.properties

где префикс — имя пакета реализации контекста поставщика, где каждая точка (".") заменяется слешем ("/"). Например, предположим, что поставщик услуг определяет реализацию контекста с именем класса com.sun.jndi.ldap.LdapCtx. Файл ресурсов поставщика для этого поставщика называется com/sun/jndi/ldap/jndiprovider.properties. Если класс не находится в пакете, имя ресурса просто jndiprovider.properties.

Некоторые методы в библиотеке классов JNDI используют стандартные свойства JNDI, которые задают списки JNDI-фабрик:

• java.naming.factory.object
• java.naming.factory.state
• java.naming.factory.control
• java.naming.factory.url.pkgs

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

Файлы ресурсов приложения

Когда приложение развернуто, в его пути к классам обычно присутствует несколько каталогов кода и JAR-файлов. JNDI находит (используя ClassLoader.getResources()) все файлы ресурсов приложения с именем jndi.properties в пути к классам. Кроме того, если каталог установки Java содержит встроенный файл свойств, обычно conf/jndi.properties, JNDI обрабатывает его как дополнительный файл ресурсов приложения. Все свойства, содержащиеся в этих файлах, помещаются в окружение начального контекста. Затем это окружение наследуется другими контекстами.

Для каждого свойства, найденного в более чем одном файле ресурсов приложения, JNDI использует первое найденное значение или, в некоторых случаях, когда это имеет смысл, конкатенирует все значения (подробности приведены ниже). Например, если свойство "java.naming.factory.object" найдено в трех файлах ресурсов приложения, список фабрик объектов представляет собой конкатенацию значений свойства из всех трех файлов. Используя эту схему, каждый развертываемый компонент отвечает за перечисление экспортируемых им фабрик. JNDI автоматически собирает и использует все эти списки экспорта при поиске классов фабрик.

Алгоритм поиска свойств

При создании начального контекста JNDI окружение контекста инициализируется свойствами, определенными в параметре окружения, переданном в конструктор, свойствами системы и файлами ресурсов приложения. См. InitialContext для получения подробной информации. Затем это начальное окружение наследуется другими экземплярами контекста.

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

1. Окружение контекста, с которым ведется работа.
2. Файл ресурсов поставщика (jndiprovider.properties) для контекста, с которым ведется работа.

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

Когда поставщику услуг нужно определить значение свойства, он обычно берет это значение непосредственно из окружения. Поставщик услуг может определить специфичные для поставщика свойства, которые помещаются в собственный файл ресурсов поставщика. В этом случае он должен объединять значения, как описано в предыдущем абзаце.

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