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

public interface Context

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

Имена

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

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

Для систем, поддерживающих федерацию, аргументы имен String в методах Context являются составными именами. Аргументы имен, которые являются экземплярами CompositeName, обрабатываются как составные имена, а аргументы Name, которые не являются экземплярами 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.properties, список фабрик объектов представляет собой конкатенацию значений свойства из всех трёх файлов. С помощью этого метода каждый компонент, подлежащий развертыванию, отвечает за указание фабрик, которые он экспортирует. JNDI автоматически собирает и использует все эти списки экспорта при поиске классов фабрик.

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

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

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

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

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

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

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