Spec-Zone .ru
спецификации, руководства, описания, API
|
|
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 каждое имя относительно контекста. Нет никакого понятия "абсолютных имен." Приложение может загрузиться, получая его первый контекст class InitialContext :
public class InitialContext implements Context {
public InitialContext()...;
...
}
Начальный контекст содержит множество привязки, которая поднимает трубку клиент к полезным и совместно используемым контекстам от одной или более систем именования, таких как пространство имен URL или корень DNS.
Name интерфейс представляет родовое название - упорядоченная последовательность компонентов. Каждый Context метод, который берет a Name у параметра есть дубликат, который берет имя в качестве a String вместо этого. Использование версий Name полезны для приложений, которые должны управлять именами: создание их, сравнение компонентов, и так далее. Использование версий String вероятно, будут более полезными для простых приложений, такими как те, которые просто читают на имя и ищут соответствующий объект. String параметр имени представляет составное имя. Name параметр может представить составное имя или составное имя.
CompositeName class представляет последовательность имен (атомарный или составной) от многократных пространств имен. Если Name параметр, предоставленный методу Context class является экземпляром CompositeName , имя представляет составное имя.
Если Name параметр, предоставленный методу Context class не является экземпляром CompositeName , имя представляет составное имя, которое может быть представлено CompoundName class или некоторая другая реализация class. CompoundName class представляет иерархические имена от единого пространства имен. Синтаксический анализатор имени контекста может использоваться, чтобы управлять составными именами в синтаксисе, связанном с тем определенным контекстом:
public interface Context {...public NameParser getNameParser(Name name) throws NamingException;...}
Браузер пространства имен является примером вида приложения, которое, возможно, должно было бы управлять именами синтаксически на этом уровне. Большинство других приложений будет работать со строками или составлять имена.
Context.lookup() обычно используемая работа. Реализация контекста может возвратиться, объект любого class требуется приложением Java. Например, клиент мог бы использовать имя принтера, чтобы искать соответствие Printer объект, и затем печатает к этому непосредственно:
Printer printer = (Printer) ctx.lookup("treekiller");
printer.print(report);
Context.listBindings() возвращает перечисление привязки имени к объекту, каждой привязки, представленной объектом class Binding . Привязка является кортежем, содержащим имя связанного объекта, имя class объекта, и объект непосредственно.
Context.list() метод подобен listBindings() , за исключением того, что это возвращает перечисление NameClassPair объекты. Каждый NameClassPair содержит имя объекта и имя class объекта. list() метод полезен для приложений, таких как браузеры, которые хотят обнаружить информацию об объектах, связанных в пределах контекста, но не нуждаются во всех фактических объектах. Хотя listBindings() предоставляет всю ту же самую информацию, это - потенциально намного более дорогая работа.
public class NameClassPair ... {
public String getName() ...;
public String getClassName() ...;
...
}
public class Binding extends NameClassPair {
public Object getObject() ...;
...
}
Отличающийся Context реализации в состоянии связать различные виды объектов исходно. Особенно полезный объект, который должен поддерживаться любой реализацией контекста общего назначения, Reference class. Ссылка представляет объект, который существует за пределами каталога. Ссылки используются, чтобы дать клиентам JNDI иллюзию, что объекты произвольных классов в состоянии быть связанными в именовании или службах каталогов - таких как X.500 - у которых нет собственной поддержки объектов в языке программирования Java.
Когда результат работы такой как Context.lookup() или Binding.getObject() a Reference объект, JNDI пытается преобразовать ссылку в объект, который это представляет прежде, чем возвратить это клиенту. Особенно существенный экземпляр этого происходит когда ссылка, представляющая a Context из одного именования система связывается с именем в различной системе именования. Это - то, как многократные независимые системы именования объединяются в пространство имен составного объекта JNDI. Детали того, как этот механизм работает, обеспечиваются в документе SPI JNDI.
Объекты, которые в состоянии быть представленными ссылкой, должны реализовать Referenceable интерфейс. Его единственный метод- getReference() - возвращает ссылку объекта. Когда такой объект связывается с именем в любом контексте, реализация контекста могла бы сохранить ссылку в базовой системе, если объект не может храниться исходно.
Каждая ссылка может содержать имя class объекта, который это представляет, и может также содержать расположение (обычно URL), где файл class для того объекта может быть найден. Кроме того, ссылка содержит последовательность объектов class RefAddr . Каждый RefAddr поочередно содержит строку "типа" и некоторые данные адресации, обычно строка или байтовый массив.
Специализация Reference вызванный a LinkRef используется, чтобы добавить "символьные" ссылки в пространство имен JNDI. Это содержит имя объекта JNDI. По умолчанию эти ссылки сопровождаются всякий раз, когда имена JNDI разрешаются.
Некоторое именование/службы каталогов поддерживает понятие отсылок для того, чтобы перенаправить запрос клиента к другому серверу. Клиент JNDI может запросить, чтобы отсылки автоматически сопровождались, быть проигнорированными, или быть обработанными вручную.
Абстрактный class 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() выполняет указанную работу на каждом элементе ряда атрибутов. Вторая форма берет массив объектов class 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 содержа перечисление объектов class 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 это содержит описания class об определенном объекте каталога.
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 class определяет четыре типа событий:
OBJECT_ADDEDOBJECT_REMOVEDOBJECT_RENAMEDOBJECT_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 class и соответствие UnsolicitedNotificationListener интерфейс. Приложение регистрируется, чтобы получить UnsolicitedNotificationEvent s, предоставляя UnsolicitedNotificationListener к EventContext.addNamingListener() .
1. См. Приложение C для легенды о схеме class.
2. См. Приложение C для легенды о схеме class.
3. См. Приложение C для легенды о схеме class.
4. См. Приложение C для легенды о схеме class.
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT
