Spec-Zone .ru
спецификации, руководства, описания, API
|
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
API JNDI содержится в четырех пакетах:
javax.naming
содержит классы и интерфейсы для того, чтобы получить доступ к службам именованияjavax.naming.directory
расширяет ядро javax.naming
пакет, чтобы обеспечить доступ к каталогамjavax.naming.event
содержит классы и интерфейсы для того, чтобы поддерживать уведомление о событии в именовании и службах каталоговjavax.naming.ldap
содержит классы и интерфейсы для того, чтобы поддерживать LDAP v3 расширения и средства управленияИнтерфейс поставщика услуг JNDI содержится один пакет:
Следующие разделы обеспечивают краткий обзор API JNDI. Для получения дополнительной информации на API, см. соответствующий javadoc.
javax.naming
1(классы исключений не показывают),
Context
базовый интерфейс, который определяет контекст именования. Это определяет основные операции, такие как добавление привязки имени к объекту, поиск объект, связанный с указанным именем, перечисление привязки, удаление привязки имени к объекту, создание и уничтожение подконтекстов того же самого типа, и т.д.
public interface Context { public Object lookup(Name name) throws NamingException; public void bind(Name name, Object obj) throws NamingException; public void rebind(Name name, Object obj) throws NamingException; public void unbind(Name name) throws NamingException; public void rename(Name old, Name new) throws NamingException; public NamingEnumeration listBindings(Name name) throws NamingException; ... public Context createSubcontext(Name name) throws NamingException; public void destroySubcontext(Name name) throws NamingException; ... };
Каждый метод именования в Context
берет имя в качестве параметра. Работа, определенная методом, выполняется на Context
объект, который получается, неявно разрешая имя. Если имя пусто (""), работа выполняется непосредственно на контексте непосредственно. Имя объекта может быть составным именем, отражающим расположение пространств имен, используемых, чтобы обратиться к объекту. Конечно, клиент не представляется никакой реализации службы именования. Фактически, новый тип именования службы может быть представлен, не требуя, чтобы приложение было изменено или даже разрушено, если это работает.
В JNDI каждое имя относительно контекста. Нет никакого понятия "абсолютных имен." Приложение может загрузиться, получая его первый контекст класса InitialContext
:
public class InitialContext implements Context { public InitialContext()...; ... }
Начальный контекст содержит множество привязки, которая поднимает трубку клиент к полезным и совместно используемым контекстам от одной или более систем именования, таких как пространство имен URL или корень DNS.
Name
интерфейс представляет родовое название - упорядоченная последовательность компонентов. Каждый Context
метод, который берет a Name
у параметра есть дубликат, который берет имя в качестве a String
вместо этого. Использование версий Name
полезны для приложений, которые должны управлять именами: создание их, сравнение компонентов, и так далее. Использование версий String
вероятно, будут более полезными для простых приложений, такими как те, которые просто читают на имя и ищут соответствующий объект. String
параметр имени представляет составное имя. Name
параметр может представить составное имя или составное имя.
CompositeName
класс представляет последовательность имен (атомарный или составной) от многократных пространств имен. Если Name
параметр, предоставленный методу Context
класс является экземпляром CompositeName
, имя представляет составное имя.
Если Name
параметр, предоставленный методу Context
класс не является экземпляром CompositeName
, имя представляет составное имя, которое может быть представлено CompoundName
класс или некоторый другой класс реализации. CompoundName
класс представляет иерархические имена от единого пространства имен. Синтаксический анализатор имени контекста может использоваться, чтобы управлять составными именами в синтаксисе, связанном с тем определенным контекстом:
public interface Context {
...
public NameParser getNameParser(Name name) throws NamingException;
...
}
Браузер пространства имен является примером вида приложения, которое, возможно, должно было бы управлять именами синтаксически на этом уровне. Большинство других приложений будет работать со строками или составлять имена.
Context.lookup()
обычно используемая работа. Реализация контекста может возвратиться, объект любого класса требуется приложением Java. Например, клиент мог бы использовать имя принтера, чтобы искать соответствие Printer
объект, и затем печатает к этому непосредственно:
Printer printer = (Printer) ctx.lookup("treekiller"); printer.print(report);
Context.listBindings()
возвращает перечисление привязки имени к объекту, каждой привязки, представленной объектом класса Binding
. Привязка является кортежем, содержащим имя связанного объекта, имя класса объекта, и объект непосредственно.
Context.list()
метод подобен listBindings()
, за исключением того, что это возвращает перечисление NameClassPair
объекты. Каждый NameClassPair
содержит имя объекта и имя класса объекта. list()
метод полезен для приложений, таких как браузеры, которые хотят обнаружить информацию об объектах, связанных в пределах контекста, но не нуждаются во всех фактических объектах. Хотя listBindings()
предоставляет всю ту же самую информацию, это - потенциально намного более дорогая работа.
public class NameClassPair ... { public String getName() ...; public String getClassName() ...; ... } public class Binding extends NameClassPair { public Object getObject() ...; ... }
Отличающийся Context
реализации в состоянии связать различные виды объектов исходно. Особенно полезный объект, который должен поддерживаться любой реализацией контекста общего назначения, Reference
класс. Ссылка представляет объект, который существует за пределами каталога. Ссылки используются, чтобы дать клиентам JNDI иллюзию, что объекты произвольных классов в состоянии быть связанными в именовании или службах каталогов - таких как X.500 - у которых нет собственной поддержки объектов в языке программирования Java.
Когда результат работы такой как Context.lookup()
или Binding.getObject()
a Reference
объект, JNDI пытается преобразовать ссылку в объект, который это представляет прежде, чем возвратить это клиенту. Особенно существенный экземпляр этого происходит когда ссылка, представляющая a Context
из одного именования система связывается с именем в различной системе именования. Это - то, как многократные независимые системы именования объединяются в пространство имен составного объекта JNDI. Детали того, как этот механизм работает, обеспечиваются в документе SPI JNDI.
Объекты, которые в состоянии быть представленными ссылкой, должны реализовать Referenceable
интерфейс. Его единственный метод- getReference()
- возвращает ссылку объекта. Когда такой объект связывается с именем в любом контексте, реализация контекста могла бы сохранить ссылку в базовой системе, если объект не может храниться исходно.
Каждая ссылка может содержать имя класса объекта, который это представляет, и может также содержать расположение (обычно URL), где файл класса для того объекта может быть найден. Кроме того, ссылка содержит последовательность объектов класса RefAddr
. Каждый RefAddr
поочередно содержит строку "типа" и некоторые данные адресации, обычно строка или байтовый массив.
Специализация Reference
вызванный a LinkRef
используется, чтобы добавить "символьные" ссылки в пространство имен JNDI. Это содержит имя объекта JNDI. По умолчанию эти ссылки сопровождаются всякий раз, когда имена JNDI разрешаются.
Некоторое именование/службы каталогов поддерживает понятие отсылок для того, чтобы перенаправить запрос клиента к другому серверу. Клиент JNDI может запросить, чтобы отсылки автоматически сопровождались, быть проигнорированными, или быть обработанными вручную.
Абстрактный класс ReferralException
используется, чтобы представить отсылку:
public abstract class ReferralException extends NamingException { public abstract Context getReferralContext() throws NamingException; ... public abstract Object getReferralInfo(); public abstract void retryReferral(); public abstract boolean skipReferral(); }
Когда с отсылкой встречаются, и клиент запросил, чтобы отсылки не были проигнорированы или автоматически сопровождались, a ReferralException
бросается. getReferralInfo()
метод предоставляет информацию - в формате, соответствующем поставщику услуг - о том, куда отсылка ведет. Приложение не обязано исследовать эту информацию; однако, это могло бы хотеть представлять это человеческому пользователю, чтобы помочь ему определить, следовать ли за отсылкой или нет. skipReferral()
позволяет приложению отбрасывать отсылку и продолжаться к следующей отсылке (если любой).
Чтобы продолжать работу, приложение повторно вызывает метод на контекст отсылки, используя те же самые параметры, которые это предоставляло к исходному методу.
javax.naming.directory
2(классы исключений не показывают),
DirContext
взаимодействуйте через интерфейс включает возможности каталога, определяя методы для исследования и обновления атрибутов, связанных с объектом каталога.
public interface DirContext extends Context { public Attributes getAttributes(Name name) throws NamingException; public Attributes getAttributes(Name name, String[] attrIds) throws NamingException; ... public void modifyAttributes(Name name, int modOp, Attributes attrs) throws NamingException; public void modifyAttributes(Name name, ModificationItem[] mods) throws NamingException; ... }
getAttributes()
операции на каталоге возвращают некоторых или все его атрибуты. Атрибуты изменяются, используя две формы modifyAttributes()
. Обе формы используют "работу модификации," один из:
ADD_ATTRIBUTE REPLACE_ATTRIBUTE REMOVE_ATTRIBUTE
ADD_ATTRIBUTE
работа добавляет значения к атрибуту, если тот атрибут уже существует, в то время как REPLACE_ATTRIBUTE
работа отбрасывает любые существующие ранее значения. Первая форма modifyAttributes()
выполняет указанную работу на каждом элементе ряда атрибутов. Вторая форма берет массив объектов класса ModificationItem
:
public class ModificationItem { public ModificationItem(int modOp, Attribute attr) ...; ... }
Каждая работа выполняется на ее соответствующем атрибуте в определенном порядке. Когда возможный, реализация контекста должна выполнить каждый звонок modifyAttributes()
как атомарная работа.
Объект каталога содержит ряд нуля или больше Attribute
объекты. Каждый атрибут обозначается строковым идентификатором и может иметь нуль или больше значений любого типа.
public interface Attribute ... { ... public String getID(); public Object get(int n) throws NamingException; public boolean isOrdered(); public NamingEnumeration getAll() throws NamingException; ... }
Значения атрибута могут быть упорядочены или неупорядочены. Если значения неупорядочиваются, никакие копии не позволяются. Если значения упорядочиваются, копии позволяются.
Атрибуты группируются в набор при использовании Attributes
интерфейс.
public interface Attributes ... { ... public Attribute get(String attrID); public NamingEnumeration getIDs(); public NamingEnumeration getAll(); public Attribute put(Attribute attr); public Attribute remove(String attrID); ... }
JNDI обеспечивает реализации для этих двух интерфейсов, BasicAttribute
и BasicAttributes
, для удобства. Поставщики услуг и приложения свободны использовать свои собственные реализации.
Отметьте что обновления к Attributes
и Attribute
, такой как добавление или удаление атрибута или его значения, не влияйте на соответствующее представление в каталоге. Обновления к каталогу могут только быть произведены при использовании DirContext.modifyAttributes()
.
DirContext
интерфейс также ведет себя как контекст именования, расширяясь Context
интерфейс. Это означает, что любой объект каталога может также обеспечить контекст именования. В дополнение к объекту каталога, сохраняющему множество информации о человеке, например, это - также естественный контекст именования для ресурсов, связанных с тем человеком: принтеры человека, файловая система, календарь, и т.д.
Гибридные операции выполняют определенное именование и операции каталога в единственной атомарной работе:
public interface DirContext extends Context { ... public void bind(Name name, Object obj, Attributes attrs) throws NamingException; ... }
Другие гибридные операции, которые обеспечиваются, rebind()
и createSubcontext()
это принимает дополнительное Attributes
параметр.
Приложение, которое выполняет операции каталога, может использовать InitialDirContext
вместо javax.naming.InitialContext
создать его начальный контекст:
public class InitialDirContext extends InitialContext implements DirContext { public InitialDirContext() ...; ... }
Это может тогда вызвать любой метод в Context
или DirContext
интерфейс на начальном контексте.
DirContext
интерфейс поддерживает основанный на контенте поиск каталогов. В самом простом и наиболее распространенной форме использования, приложение определяет ряд атрибутов - возможно с определенными значениями - чтобы соответствовать. Это тогда вызывает DirContext.search()
метод на объекте каталога, который возвращает соответствующие объекты каталога наряду с требуемыми атрибутами.
public interface DirContext extends Context { ... public NamingEnumeration search(Name name, Attributes matchingAttributes) throws NamingException; public NamingEnumeration search(Name name, Attributes matchingAttributes, String[] attributesToReturn) throws NamingException; ... }
Результаты поиска возвращаются как a NamingEnumeration
содержа перечисление объектов класса SearchResult
:
public class SearchResult extends Binding { ... public Attributes getAttributes() ...; }
В более сложном случае возможно определить поисковый фильтр и предоставить информацию об управлении, такую как контекст поиска и максимальный размер результатов. Поисковый фильтр определяет синтаксис, который следует за Интернетом RFC 2254 для LDAP. SearchControls
параметр определяет такие вещи как контекст поиска: это может включать единственный объект каталога, все его дочерние элементы, или всех его потомков в иерархии каталогов.
public interface DirContext extends Context { ... public NamingEnumeration search(Name name, String filter, SearchControls ctls) throws NamingException; public NamingEnumeration search(Name name, String filter, Object[] filterArgs, SearchControls ctls) throws NamingException; ... }
Схема описывает правила, которые определяют структуру пространства имен и атрибутов, сохраненных в пределах нее. Гранулярность схемы может колебаться от единственной схемы, которая связывается со всем пространством имен к мелкомодульному описанию схемы на атрибут.
Поскольку схемы могут быть выражены как информационное дерево, естественно использовать с этой целью именование и интерфейсы каталога, уже определенные в JNDI. Это мощно, потому что часть схемы пространства имен доступна для приложений универсальным способом. Браузер, например, может получить доступ к информации в дереве схемы, как если бы это получало доступ к любым другим объектам каталога.
Приложения могут получить схему, связанную с объектом каталога, когда базовая реализация контекста оказывает соответствующую поддержку.
DirContext.getSchema()
используется, чтобы получить корень дерева схемы, связанного с объектом каталога. У корня есть дочерние элементы, такие как "ClassDefinition", "AttributeDefinition", и "SyntaxDefinition", каждый обозначающий вид описываемого определения. Корень схемы и его потомки являются объектами типа DirContext
. DirContext.getSchemaClassDefinition()
метод возвращает a DirContext
это содержит описания класса об определенном объекте каталога.
public interface DirContext extends Context { ... public DirContext getSchema(Name name) throws NamingException; public DirContext getSchemaClassDefinition(Name name) throws NamingException; ... }
Кроме того, к схеме, связанной с любым атрибутом, можно получить доступ, используя Attribute.getAttributeDefinition()
и getAttributeSyntaxDefinition()
методы.
public interface Attribute ... { ... public DirContext getAttributeDefinition() throws NamingException; public DirContext getAttributeSyntaxDefinition() throws NamingException; ... }
Каталог отображения в качестве примера к Схеме является примером, показывая различным ассоциациям для того, чтобы получить доступ к информации о схеме.
javax.naming.event
3Документация API." ШИРИНА = "769" ВЫСОТА = "258" ВЫРАВНИВАЕТСЯ = "НИЖНЯЯ" ГРАНИЦА = "0">
javax.naming.event
пакет содержит классы и интерфейсы для того, чтобы поддерживать уведомление о событии в именовании и службах каталогов.
A NamingEvent
представляет событие, которое сгенерировано именованием/службой каталогов.
public class NamingEvent extends java.util.EventObject { ... public int getType(); public Binding getOldBinding(); public Binding getNewBinding(); ... }
Тип события идентифицирует тип события. NamingEvent
класс определяет четыре типа событий:
OBJECT_ADDED
OBJECT_REMOVED
OBJECT_RENAMED
OBJECT_CHANGED
Эти типы могут быть помещены в две категории:
В дополнение к типу события, a NamingEvent
содержит другую информацию об изменении, таком как информация об объекте прежде и после изменения.
Слушатель именования является объектом, который регистрируется для NamingEvent
s. Это представляется интерфейсом NamingListener
. Каждая категория NamingEvent
обрабатывается соответствующим подтипом NamingListener
. NamespaceChangeListener
интерфейс представляет слушателя, заинтересованного изменениями пространства имен, в то время как ObjectChangeListener
представляет слушателя, заинтересованного изменениями к содержанию объекта. Реализация слушателя могла бы реализовать один или оба из этих интерфейсов, в зависимости от типов событий, которыми она интересуется.
EventContext
и EventDirContext
интерфейсы расширяются Context
и DirContext
интерфейсы, соответственно, чтобы поддерживать регистрацию события и deregistration.
public interface EventContext extends Context { ... public void addNamingListener(Name target, int scope, NamingListener l) throws NamingException; public void removeNamingListener(NamingListener l) throws NamingException; public boolean targetMustExist() throws NamingException; }
Как методы в соответствии Context
интерфейс, addNamingListener()
имеет перегрузку, которая принимает a String
параметр имени. Параметр имени упоминается как цель. Параметр контекста определяет, является ли регистрация для объекта, названного к установленному сроку, непосредственные дочерние элементы контекста, названного к установленному сроку, или все поддерево базировалось в объекте, названном к установленному сроку.
Возможно зарегистрировать интерес к цели, которая не существует, но могли бы быть ограничения в степени, до которой это может поддерживаться поставщиком услуг и базовым протоколом/службой. Приложение может использовать метод targetMustExist()
проверять ли EventContext
поддерживает регистрацию несуществующих целей.
public interface EventDirContext extends EventContext, DirContext { public void addNamingListener(Name target, String filter, SearchControls ctls, NamingListener l) throws NamingException; public void addNamingListener(Name target, String filter, Object[] filterArgs, SearchControls ctls, NamingListener l) throws NamingException; ... }
EventDirContext
интерфейс расширяется EventContext
и DirContext
интерфейсы, чтобы позволить слушателю регистрировать интерес к объектам, идентифицированным, используя поисковые фильтры (Интернет RFC 2254).
Как методы в соответствии DirContext
интерфейс, addNamingListener()
у методов есть перегрузки, которые принимают a String
параметр имени.
EventContext/EventDirContext
экземпляр тот, на который addNamingListener()
метод вызывается, источник события событий, которые (потенциально) сгенерированы. Когда зарегистрированный слушатель вызывает getSource()
или getEventContext()
на a NamingEvent
, результат будет этим EventContext
/ EventDirContext
экземпляр.
Например, предположите, что слушатель делает следующую регистрацию:
NamespaceChangeListener listener = ...; src.addNamingListener("x", SUBTREE_SCOPE, listener);
Когда объект, названный "x/y", впоследствии удаляется, соответствие NamingEvent
( evt
) поставленный listener
должен содержать src
как его источник события. Следующее оба будет истиной:
evt.getEventContext() == src evt.getOldBinding().getName().equals("x/y")
Когда слушатель регистрируется для событий в контексте, контекст, возможно, должен был бы сделать некоторую внутреннюю обработку, чтобы собрать информацию, требуемую генерировать события. Контекст, например, возможно, должен был бы обратиться с просьбой к серверу, чтобы зарегистрировать интерес к изменениям на сервере, который будет в конечном счете преобразован в события. Если ошибка произойдет, который предотвращает информацию о событиях от того, чтобы быть собранным, то слушатель никогда не будет уведомляться относительно событий. Когда такая ошибка происходит, a NamingExceptionEvent
запускается, чтобы уведомить слушателя, и слушатель автоматически вычеркивается из списка.
Основа NamingListener
интерфейс определяет a namingExceptionThrown()
метод так, чтобы слушатель мог быть уведомлен относительно такой ошибки.
public interface NamingListener extends java.util.EventListener { public void namingExceptionThrown(NamingExceptionEvent evt); }
javax.naming.ldap
4
javax.naming.ldap
пакет содержит классы и интерфейсы для того, чтобы использовать LDAP v3-specific функции, которые уже не покрываются более универсальным javax.naming.directory
пакет. Фактически, большинство приложений JNDI, которые используют LDAP, найдет javax.naming.directory
достаточный пакет, и не должен будет использовать этот пакет вообще. Этот пакет прежде всего для тех приложений, которые должны использовать расширенные операции, средства управления, или незапрашиваемые уведомления.
В дополнение к определению четко определенных операций, таких как поиск и изменяют, LDAP v3 протокол (Интернет RFC 2251) определяет способ передать все же будущие определенные операции между клиентом и сервером LDAP. Эти операции упоминаются как расширенные операции. Расширенная работа может быть определена организацией стандартов, такой как IETF или поставщиком.
LdapContext
интерфейс определяет метод для того, чтобы выполнить расширенную работу:
public interface LdapContext extends DirContext { public ExtendedResponse extendedOperation(ExtendedRequest request) throws NamingException; ... }
ExtendedRequest
интерфейс представляет параметр расширенной работе, в то время как ExtendedResponse
интерфейс представляет результат расширенной работы. ExtendedRequest
или ExtendedResponse
состоит из идентификатора, который идентифицирует расширенную работу и байтовый массив, содержащий BER ASN.1 закодированное содержание запроса/ответа.
Приложение обычно не имеет дело непосредственно с ExtendedRequest
/ ExtendedResponse
интерфейсы. Вместо этого это имеет дело с классами, которые реализуют эти интерфейсы. Приложение получает эти классы или как часть репертуара расширенных операций, стандартизированных через IETF, или от поставщиков каталога для специфичных для поставщика расширенных операций. У классов запроса должны быть конструкторы, которые принимают параметры безопасным с точки зрения типов и удобным для пользователя способом, в то время как у классов ответа должны быть методы доступа для того, чтобы получить данные ответа безопасным с точки зрения типов и удобным для пользователя способом. Внутренне, классы запроса/ответа имеют дело с кодированием и декодированием значений BER.
Например, предположите, что сервер LDAP поддерживает, "получают время" расширенная работа. Это предоставило бы классы такой как GetTimeRequest
и GetTimeResponse
, так, чтобы приложения могли использовать эту функцию. Приложение использовало бы эти классы следующим образом:
GetTimeResponse resp = (GetTimeResponse)lctx.extendedOperation(new GetTimeRequest()); long time = resp.getTime();
LDAP v3 протокол (Интернет RFC 2251) позволяет любому запросу или ответу быть увеличенным все же будущими определенными модификаторами. Эти модификаторы упоминаются как средства управления. Средства управления, которые отправляются с запросами, вызывают средствами управления запросом и теми, которые отправляются с ответами, вызываются средствами управления ответом. Управление может быть определено организацией стандартов, такой как IETF или поставщиком. Есть не обязательно соединение между средствами управления запросом и средствами управления ответом.
JNDI классифицирует средства управления запросом в две категории:
Средства управления запросом соединения используются всякий раз, когда соединение должно быть установлено или восстановлено с сервером LDAP. Средства управления запросом контекста используются, когда все другие операции LDAP отправляются серверу LDAP. Причина этого различия состоит в том, потому что JNDI является высокоуровневым API, который не имеет дело непосредственно с соединениями. Это - задание поставщиков услуг, чтобы сделать любое необходимое управление соединением. Следовательно, единственное соединение могло бы быть совместно использовано многократными экземплярами контекста, и поставщик услуг свободен использовать его собственные алгоритмы, чтобы сохранить соединение и сетевое использование. Таким образом, когда метод вызывается на экземпляр контекста, поставщик услуг, возможно, должен был бы сделать некоторое управление соединением в дополнение к выполнению соответствующих операций LDAP. Для управления соединением это использует средства управления запросом соединения, в то время как для нормальных операций LDAP, это использует средства управления запросом контекста.
LdapContext
интерфейс определяет методы для того, чтобы иметь дело со средствами управления:
public interface LdapContext extends DirContext { public void reconnect(Control[] connCtls) throws NamingException; public Control[] getConnectControls() throws NamingException; ... public LdapContext newInstance(Control[] reqCtls) throws NamingException; public void setRequestControls(Control[] reqCtls) throws NamingException; public Control[] getRequestControls() throws NamingException; ... public Control[] getResponseControls() throws NamingException; }
Control
интерфейс представляет управление. Это состоит из идентификатора, который идентифицирует управление и байтовый массив, содержащий BER ASN.1 закодированное содержание управления.
Средства управления запросом соединения инициализируются, используя начального конструктора контекста и наследованы контекстами, которые получаются из контекста. reconnect()
используется, чтобы изменить средства управления запросом соединения контекста. Средства управления запросом соединения контекста получаются, используя getConnectControls()
.
Средства управления запросом контекста инициализируются, используя newInstance()
и измененное использование setRequestControls()
. newInstance()
метод удобства для того, чтобы создать новый экземпляр контекста в целях многопоточного доступа. Например, если многократные потоки хотят использовать различные средства управления запросом контекста, каждый поток может использовать этот метод, чтобы получить его собственную копию этого контекста и установить/получить средства управления запросом контекста, не имея необходимость синхронизироваться с другими потоками.
В отличие от средств управления запросом соединения, средства управления запросом контекста не наследованы экземплярами контекста, которые получаются из контекста. Полученные экземпляры контекста инициализируются без средств управления запросом контекста. Следует установить средства управления запросом полученного экземпляра контекста, явно используя setRequestControls()
. Средства управления запросом контекста контекста получаются, используя getRequestControls()
.
Приложение, которое выполняет LDAP расширенные операции или средства управления, может использовать InitialLdapContext
вместо javax.naming.InitialContext
или javax.naming.directory.InitialDirContext
создать его начальный контекст:
public class InitialLdapContext extends InitialDirContext implements LdapContext { public InitialDirContext() ...; public InitialDirContext(Hashtable env, Control[] connCtls) ...; }
Это может тогда вызвать любой метод в Context
, DirContext
, или LdapContext
интерфейсы на начальном контексте. При использовании конструктора, который принимает a connCtls
параметр, приложение может определить средства управления, которые будут использоваться, устанавливая соединение с сервером LDAP.
В дополнение к нормальному стилю запроса/ответа взаимодействия между клиентом и сервером LDAP v3 протокол также определяет незапрашиваемые уведомления - сообщения, которые отправляются от сервера до клиента асинхронно, не в ответ на любой клиентский запрос.
JNDI поддерживает незапрашиваемые уведомления, используя модель событий, воплощенную в javax.naming.event
пакет. Это определяет UnsolicitedNotificationEvent
класс и соответствие UnsolicitedNotificationListener
интерфейс. Приложение регистрируется, чтобы получить UnsolicitedNotificationEvent
s, предоставляя UnsolicitedNotificationListener
к EventContext.addNamingListener()
.
1. См. Приложение C для легенды о диаграмме классов.
2. См. Приложение C для легенды о диаграмме классов.
3. См. Приложение C для легенды о диаграмме классов.
4. См. Приложение C для легенды о диаграмме классов.
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT