< prev index next >

src/java.naming/share/classes/javax/naming/ldap/package.html

Print this page


   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <html>
   3 <head>
   4 <!--
   5 Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights reserved.
   6 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   7 
   8 This code is free software; you can redistribute it and/or modify it
   9 under the terms of the GNU General Public License version 2 only, as
  10 published by the Free Software Foundation.  Oracle designates this
  11 particular file as subject to the "Classpath" exception as provided
  12 by Oracle in the LICENSE file that accompanied this code.
  13 
  14 This code is distributed in the hope that it will be useful, but WITHOUT
  15 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  16 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  17 version 2 for more details (a copy is included in the LICENSE file that
  18 accompanied this code).
  19 
  20 You should have received a copy of the GNU General Public License version
  21 2 along with this work; if not, write to the Free Software Foundation,
  22 Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  23 
  24 Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  25 or visit www.oracle.com if you need additional information or have any


  31 
  32 Provides support for LDAPv3 extended operations and controls.
  33 
  34 <p>
  35 This package extends the directory operations of the Java Naming and
  36 Directory Interface&trade; (JNDI). &nbsp;
  37 JNDI provides naming and directory functionality to applications
  38 written in the Java programming language.  It is designed to be
  39 independent of any specific naming or directory service
  40 implementation.  Thus a variety of services--new, emerging, and
  41 already deployed ones--can be accessed in a common way.
  42 
  43 <p>
  44 This package is for applications and service providers that deal with
  45 LDAPv3 extended operations and controls, as defined by
  46 <a href=http://www.ietf.org/rfc/rfc2251.txt>RFC 2251</a>.
  47 The core interface in this package is <code>LdapContext</code>, which defines
  48 methods on a context for performing extended operations and handling
  49 controls.
  50 
  51 <h2>Extended Operations</h2>
  52 <p>
  53 This package defines the interface <code>ExtendedRequest</code>
  54 to represent the argument to an extended operation,
  55 and the interface <code>ExtendedResponse</code> to represent the result
  56 of the extended operation.
  57 An extended response is always paired with an extended request
  58 but not necessarily vice versa. That is, you can have an extended request
  59 that has no corresponding extended response.
  60 <p>
  61 An application typically does not deal directly with these interfaces.
  62 Instead, it deals with classes that <em>implement</em> these
  63 interfaces.  
  64 The application gets these classes either as part of a
  65 repertoire of extended operations standardized through the IETF, or
  66 from directory vendors for vendor-specific extended operations.
  67 The request classes should have constructors that accept
  68 arguments in a type-safe and user-friendly manner, while the
  69 response classes should have access methods for getting the data
  70 of the response in a type-safe and user-friendly manner.
  71 Internally, the request/response classes deal with encoding and decoding


 108     public GetTimeResponse(String id, byte[] berValue, int offset, int length)
 109         throws NamingException {
 110         // check validity of id
 111         long time =  ... // decode berValue to get time
 112     }
 113 
 114     // Type-safe and User-friendly methods
 115     public java.util.Date getDate() { return new java.util.Date(time); }
 116     public long getTime() { return time; }
 117 
 118     // Low level methods
 119     public byte[] getEncodedValue() {
 120         return // berValue saved;
 121     }
 122     public String getID() {
 123         return GETTIME_RESP_OID;
 124     }
 125 }
 126 </pre></blockquote>
 127 
 128 <h2>Controls</h2>
 129 
 130 This package defines the interface <code>Control</code> to represent an LDAPv3
 131 control. It can be a control that is sent to an LDAP server
 132 (<em>request control</em>) or a control returned by an LDAP server
 133 (<em>response control</em>).  Unlike extended requests and responses,
 134 there is not necessarily any pairing between request controls and
 135 response controls.  You can send request controls and expect no
 136 response controls back, or receive response controls without sending
 137 any request controls.
 138 <p>
 139 An application typically does not deal directly with this interface.
 140 Instead, it deals with classes that <em>implement</em> this interface.
 141 The application gets control classes either as part of a repertoire of
 142 controls standardized through the IETF, or from directory vendors for
 143 vendor-specific controls.  The request control classes should have
 144 constructors that accept arguments in a type-safe and user-friendly
 145 manner, while the response control classes should have access methods
 146 for getting the data of the response in a type-safe and user-friendly
 147 manner.  Internally, the request/response control classes deal with
 148 encoding and decoding BER values.


   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <html>
   3 <head>
   4 <!--
   5 Copyright (c) 1999, 2006, Oracle and/or its affiliates. All rights reserved.
   6 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   7 
   8 This code is free software; you can redistribute it and/or modify it
   9 under the terms of the GNU General Public License version 2 only, as
  10 published by the Free Software Foundation.  Oracle designates this
  11 particular file as subject to the "Classpath" exception as provided
  12 by Oracle in the LICENSE file that accompanied this code.
  13 
  14 This code is distributed in the hope that it will be useful, but WITHOUT
  15 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  16 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  17 version 2 for more details (a copy is included in the LICENSE file that
  18 accompanied this code).
  19 
  20 You should have received a copy of the GNU General Public License version
  21 2 along with this work; if not, write to the Free Software Foundation,
  22 Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  23 
  24 Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  25 or visit www.oracle.com if you need additional information or have any


  31 
  32 Provides support for LDAPv3 extended operations and controls.
  33 
  34 <p>
  35 This package extends the directory operations of the Java Naming and
  36 Directory Interface&trade; (JNDI). &nbsp;
  37 JNDI provides naming and directory functionality to applications
  38 written in the Java programming language.  It is designed to be
  39 independent of any specific naming or directory service
  40 implementation.  Thus a variety of services--new, emerging, and
  41 already deployed ones--can be accessed in a common way.
  42 
  43 <p>
  44 This package is for applications and service providers that deal with
  45 LDAPv3 extended operations and controls, as defined by
  46 <a href=http://www.ietf.org/rfc/rfc2251.txt>RFC 2251</a>.
  47 The core interface in this package is <code>LdapContext</code>, which defines
  48 methods on a context for performing extended operations and handling
  49 controls.
  50 
  51 <h3>Extended Operations</h3>
  52 <p>
  53 This package defines the interface <code>ExtendedRequest</code>
  54 to represent the argument to an extended operation,
  55 and the interface <code>ExtendedResponse</code> to represent the result
  56 of the extended operation.
  57 An extended response is always paired with an extended request
  58 but not necessarily vice versa. That is, you can have an extended request
  59 that has no corresponding extended response.
  60 <p>
  61 An application typically does not deal directly with these interfaces.
  62 Instead, it deals with classes that <em>implement</em> these
  63 interfaces.  
  64 The application gets these classes either as part of a
  65 repertoire of extended operations standardized through the IETF, or
  66 from directory vendors for vendor-specific extended operations.
  67 The request classes should have constructors that accept
  68 arguments in a type-safe and user-friendly manner, while the
  69 response classes should have access methods for getting the data
  70 of the response in a type-safe and user-friendly manner.
  71 Internally, the request/response classes deal with encoding and decoding


 108     public GetTimeResponse(String id, byte[] berValue, int offset, int length)
 109         throws NamingException {
 110         // check validity of id
 111         long time =  ... // decode berValue to get time
 112     }
 113 
 114     // Type-safe and User-friendly methods
 115     public java.util.Date getDate() { return new java.util.Date(time); }
 116     public long getTime() { return time; }
 117 
 118     // Low level methods
 119     public byte[] getEncodedValue() {
 120         return // berValue saved;
 121     }
 122     public String getID() {
 123         return GETTIME_RESP_OID;
 124     }
 125 }
 126 </pre></blockquote>
 127 
 128 <h3>Controls</h3>
 129 
 130 This package defines the interface <code>Control</code> to represent an LDAPv3
 131 control. It can be a control that is sent to an LDAP server
 132 (<em>request control</em>) or a control returned by an LDAP server
 133 (<em>response control</em>).  Unlike extended requests and responses,
 134 there is not necessarily any pairing between request controls and
 135 response controls.  You can send request controls and expect no
 136 response controls back, or receive response controls without sending
 137 any request controls.
 138 <p>
 139 An application typically does not deal directly with this interface.
 140 Instead, it deals with classes that <em>implement</em> this interface.
 141 The application gets control classes either as part of a repertoire of
 142 controls standardized through the IETF, or from directory vendors for
 143 vendor-specific controls.  The request control classes should have
 144 constructors that accept arguments in a type-safe and user-friendly
 145 manner, while the response control classes should have access methods
 146 for getting the data of the response in a type-safe and user-friendly
 147 manner.  Internally, the request/response control classes deal with
 148 encoding and decoding BER values.


< prev index next >