Anwendungen entwickeln, die JNDI verwenden

Referenzen auf EJB-Home-Verzeichnisse und andere Artefakte, z. B. Datenquellen, werden an den Namespace von WebSphere Application Server gebunden. Diese Objekte können über Java™ Naming and Directory Interface (JNDI) abgerufen werden. Bevor Sie JNDI-Operationen ausführen können, benötigen Sie einen Ausgangskontext. Sie können den Ausgangskontext verwenden, um Objekte zu suchen, die an den Namespace gebunden sind.

Informationen zu diesem Vorgang

In diesen Beispielen wird das Standardverhalten der speziellen Features für die JNDI-Kontextimplementierung von WebSphere Application Server verwendet.

Die JNDI-Kontextimplementierung von WebSphere Application Server enthält spezielle Features. Mit dem JNDI-Caching wird der Durchsatz bei wiederholten Lookup-Operationen für Objekte verbessert. Es stehen mehrere Optionen für die Namenssyntax bereit, eine optimierte Option für typische JNDI-Clients sowie eine optimierte Option für die Interoperabilität mit CosNaming-Anwendungen. In den meisten Fällen entspricht das Standardverhalten dieser Features dem gewünschten Verhalten. Es gibt aber auch Situationen, in denen ein anderes Verhalten angezeigt ist.

Das JNDI-Caching und die Optionen für die Namenssyntax sind einer javax.naming.InitialContext-Instanz zugeordnet. Zum Auswählen von Optionen für diese Features definieren Sie Eigenschaften, die von der Ausgangskontextfactory von WebSphere Application Server erkannt werden. Gehen Sie wie folgt vor, um die Eigenschaften für das JNDI-Caching und die JNDI-Namenssyntax festzulegen, die für die Ausgangskontextfactory sichtbar sind:

Vorgehensweise

  1. Optional: JNDI-Caches konfigurieren

    Mit dem JNDI-Caching kann der Durchsatz von JNDI-Suchoperationen spürbar verbessert werden. Das JNDI-Caching ist standardmäßig aktiviert. In den meisten Situationen ist dieses Standardverhalten gewünscht. In bestimmten Situationen sollten jedoch andere JNDI-Cacheoptionen verwendet werden.

    Gefundene Objekte werden lokal zwischengespeichert. Nachfolgende Lookup-Operationen für zwischengespeicherte Objekte werden lokal aufgelöst. Der Cacheinhalt kann jedoch veralten. Dies ist normalerweise kein Problem, da sich die meisten Objekte, nach denen gesucht wird, nicht oft ändern. Falls Sie nach Objekten suchen müssen, die relativ häufig geändert werden, modifizieren Sie Ihre JNDI-Cacheeinstellungen.

    JNDI-Clients können mehrere Eigenschaften zum Steuern des Cacheverhaltens verwenden.

    Sie können Eigenschaften wie folgt festlegen:
    • Über die Befehlszeile durch Eingabe des tatsächlichen Zeichenfolgewertes. Beispiele:
      java -Dcom.ibm.websphere.naming.jndicache.maxentrylife=1440 
    • In einer Datei jndi.properties. Erstellen Sie dazu die Textdatei jndi.properties mit den gewünschten Eigenschaftseinstellungen. Beispiel:
      ...
      com.ibm.websphere.naming.jndicache.cacheobject=none
      ...

      Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.jndicache.cacheobject definieren.

    • Mit einem Java-Programm. Verwenden Sie dazu die in der Datei com.ibm.websphere.naming.PROPS definierten Java-Konstanten vom Typ PROPS.JNDI_CACHE*. Hier sehen Sie die Konstantendefinitionen:
      public static final String JNDI_CACHE_OBJECT =
       "com.ibm.websphere.naming.jndicache.cacheobject";
      public static final String JNDI_CACHE_OBJECT_NONE      = "none";
      public static final String JNDI_CACHE_OBJECT_POPULATED = "populated";
      public static final String JNDI_CACHE_OBJECT_CLEARED   = "cleared";
      public static final String JNDI_CACHE_OBJECT_DEFAULT   = JNDI_CACHE_OBJECT_POPULATED;
      
      
      public static final String JNDI_CACHE_NAME = "com.ibm.websphere.naming.jndicache.cachename";
      public static final String JNDI_CACHE_NAME_DEFAULT = "providerURL";
      
      public static final String JNDI_CACHE_MAX_LIFE = "com.ibm.websphere.naming.jndicache.maxcachelife";
      public static final int    JNDI_CACHE_MAX_LIFE_DEFAULT = 0;
      
      public static final String JNDI_CACHE_MAX_ENTRY_LIFE = "com.ibm.websphere.naming.jndicache.maxentrylife";
      public static final int    JNDI_CACHE_MAX_ENTRY_LIFE_DEFAULT = 0;

      Wenn Sie die vorherigen Eigenschaften in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:

      java.util.Hashtable env = new java.util.Hashtable();
      ...
      
      // Caching inaktivieren
      env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); ...
      javax.naming.Context initialContext = new javax.naming.InitialContext(env);

    Es folgen Beispiele, die veranschaulichen, wie Sie Eigenschaften des JNDI-Caches verwenden können, um das gewünschte Cacheverhalten zu erzielen. Cacheeigenschaften werden bei der Erstellung eines InitialContext-Objekts wirksam.

    Beispiel: Verhalten des JNDI-Cache über ein Programm steuern

    import java.util.Hashtable;
    import javax.naming.InitialContext;
    import javax.naming.Context;
    import com.ibm.websphere.naming.PROPS;
    
    /*****
     Das in diesem Abschnitt erläuterte Caching gehört zur Ausgangskontextfactory
     von WebSphere Application Server.  Gehen Sie davon aus, dass die Eigenschaft
     "java.naming.factory.initial" als java.lang.System-Eigenschaft auf
     "com.ibm.websphere.naming.WsnInitialContextFactory" gesetzt
     ist.
    *****/
    
    Hashtable env;
    Context ctx;
    
    // Cache löschen:
    
    env = new Hashtable();
    env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_CLEARED);
    ctx = new InitialContext(env);
    
    // Die maximale Lebensdauer eines Cache auf 60 Minuten begrenzen:
    
    env = new Hashtable();
    env.put(PROPS.JNDI_CACHE_MAX_LIFE, "60");
    ctx = new InitialContext(env);
    
    // Das Caching inaktivieren:
    
    env = new Hashtable();
    env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE);
    ctx = new InitialContext(env);
    
    // Mit und ohne Caching arbeiten:
    
    env = new Hashtable();
    env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_POPULATED);
    ctx = new InitialContext(env);
    env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE);
    Context noCacheCtx = new InitialContext(env);
    
    Object o;
    
    // Caching zum Lokalisieren des Home verwenden, da das Home nur selten geändert wird.
    o = ctx.lookup("com/mycom/MyEJBHome");
    // Narrow, etc. ...
    
    
    // Cache nicht für flüchtige Daten verwenden.
    o = noCacheCtx.lookup("com/mycom/VolatileObject");
    // ...

    Beispiel: JavaMail-Sitzung mit JNDI suchen

    Das nachfolgende Beispiel zeigt die Lookup-Operation für eine JavaMail-Ressource:

    // Ausgangskontext wie zuvor dargestellt abrufen
    ...
    Session session =
         (Session) initialContext.lookup("java:comp/env/mail/MailSession");
  2. Optional: Namenssyntax angeben

    Die INS-Syntax ist für JNDI-Clients bestimmt, die mit CORBA-Anwendungen zusammenarbeiten müssen. Diese Syntax ermöglicht einem JNDI-Client, die CORBA-Namen richtig zuzuordnen. Die INS-Syntax weicht nur geringfügig von der JNDI-Syntax ab und enthält das zusätzliche Zeichen Punkt (.). Der Punkt wird zum Trennen der Felder "id" und "kind" in einer Namenskomponente verwendet. Ein Punkt wird als solcher interpretiert, wenn ihm ein Escapezeichen vorangestellt ist. In Namenskomponenten sind nur Punkte ohne vorangestelltes Escapezeichen zulässig. Eine Namenskomponente mit einem ausgefüllten Feld "id" und einem leeren Feld "kind" wird nur mit dem Wert des Feldes "id" dargestellt und darf nicht mit einem Punkt ohne vorangestelltes Escapezeichen enden. Eine leere Namenskomponente (leeres Feld "id" und leeres Feld "kind") wird durch einen einzelnen Punkt ohne vorangestelltes Escapezeichen dargestellt. Eine leere Zeichenfolge ist keine gültige Darstellung für eine Namenskomponente.

    Die JNDI-Namenssyntax ist die Standardsyntax und eignet sich für typische JNDI-Clients. Diese Syntax umfasst folgende Sonderzeichen: Schrägstrich (/) und Backslash (\). Komponenten in einem Namen werden durch einen Schrägstrich getrennt. Der Backslash dient als Escapezeichen. Ein Schrägstrich wird als solcher interpretiert, wenn er mit einem Escapezeichen versehen ist, d. h. wenn ihm ein Backslash vorangestellt ist. Entsprechend wird ein Backslash als solcher interpretiert, wenn er mit einem Escapezeichen versehen ist.

    Die meisten WebSphere-Anwendungen verwenden JNDI für die Suche nach EJB-Objekten und müssen nicht nach Objekten suchen, die durch CORBA-Anwendungen gebunden sind. Die Standardsyntax für JNDI-Namen ist deshalb sehr komfortabel. Wenn Ihre Anwendung nach Objekten suchen muss, die durch CORBA-Anwendungen gebunden sind, müssen Sie unter Umständen die Namenssyntax so ändern, dass alle CORBA-CosNaming-Namen dargestellt werden können.

    JNDI-Clients können die Namenssyntax über eine Eigenschaft festlegen. Die Eigenschaftseinstellung wird von der Ausgangskontextfactory angewendet, wenn Sie ein neues java.naming.InitialContext-Objekt instanziieren. In JNDI-Operationen für den Ausgangskontext angegebene Namen werden entsprechend der angegebenen Namenssyntax analysiert.

    Sie können die Eigenschaft wie folgt festlegen:

    • Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein. Beispiel:
      java -Dcom.ibm.websphere.naming.name.syntax=ins
    • Erstellen Sie eine Datei mit dem Namen jndi.properties als Textdatei mit den gewünschten Eigenschaftseinstellungen. Beispiel:
      ...
      com.ibm.websphere.naming.name.syntax=ins
      ...

      Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.name.syntax definieren.

    • Verwenden Sie die Java-Konstanten PROPS.NAME_SYNTAX*, die in der Datei com.ibm.websphere.naming.PROPS definiert sind, in einem Java-Programm. Hier sehen Sie die Konstantendefinitionen:
      public static final String NAME_SYNTAX =
          "com.ibm.websphere.naming.name.syntax";
      public static final String NAME_SYNTAX_JNDI = "jndi";
      public static final String NAME_SYNTAX_INS  = "ins";

      Wenn Sie die vorherigen Eigenschaften in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:

      java.util.Hashtable env = new java.util.Hashtable();
      ...
      env.put(PROPS.NAME_SYNTAX, PROPS.NAME_SYNTAX_INS);  // Namenssyntax auf INS setzen
      ...
      javax.naming.Context initialContext = new javax.naming.InitialContext(env);

    Beispiel: Syntax für die Analyse von Namenszeichenfolgen festlegen

    Die Eigenschaft der Namenssyntax kann an den InitialContext-Konstruktor über den entsprechenden Parameter in den Systemeigenschaften oder in einer Datei jndi.properties übergeben werden. Der Ausgangskontext und alle Kontexte, die über diesen Ausgangskontext lokalisiert werden, führen eine Syntaxanalyse von Namenszeichenfolgen, die auf der angegebenen Syntax basieren, durch.

    Das folgende Beispiel zeigt, wie Sie die Namenssyntax definieren, damit der Ausgangskontext Namenszeichenfolgen gemäß INS-Syntax analysiert.

    ...
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import com.ibm.websphere.naming.PROPS; // WebSphere-Naming-Konstanten
    ...
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, 
          "com.ibm.websphere.naming.WsnInitialContextFactory");
    env.put(Context.PROVIDER_URL, ...);
    env.put(PROPS.NAME_SYNTAX, PROPS.NAME_SYNTAX_INS);
    Context initialContext = new InitialContext(env);
    // Der folgende Name wird einer CORBA-Namenskomponente wie folgt zugeordnet:
    //    id = "a.name", kind = "in.INS.format"
    // Der Punkt ohne Escape-Zeichen wird als Begrenzer verwendet.
    // Punkte mit vorangestelltem Escape-Zeichen werden als Punkte interpretiert.
    java.lang.Object o = initialContext.lookup("a\\.name.in\\.INS\\.format");
    ...

    Die INS-Namenssyntax erfordert, dass eingebetteten Punkten (.) in einem Namen, wie z. B. in.INS.format, ein Backslash (\) als Escape-Zeichen vorangestellt wird. In einem Java-Zeichenfolgeliteral muss dem Backslash (\) ein weiterer Backslash als Escape-Zeichen vorangestellt werden.

  3. Optional: Normalisierung von Hostnamen inaktivieren

    Verweise auf Hostnamen, IP-Adressen und localhost in Provider-URLs werden im Allgemeinen normalisiert. Das Format eines normalisierten Hostnamens ist das vollständig qualifizierte Format des Hostnamens. Die Normalisierung des Hostnamens verbessert die Systemeffizienz, weil sie die Verwendung des JNDI-Cache für einen bestimmten Bootstrap-Host ermöglicht, unabhängig vom Format des Verweises im Provider-URL. Wird die Normalisierung des Hostnamens durchgeführt, kann beispielsweise für die Verweise myhost, myhost.mydomain.com und localhost ein einziger JNDI-Cache verwendet werden, wenn alle Verweise sich auf denselben Host beziehen.

    Die normalisierten Hostnamen werden zwischengespeichert, daher werden nachfolgende Normalisierungen schneller durchgeführt. In manchen Netzumgebungen werden die Daten für die Domänennamenssuche dynamisch geändert, was dazu führt, dass die zwischengespeicherten Daten für die Normalisierung des Hostnamens nicht mehr aktuell sind. Möglichweise müssen Sie in manchen Umgebungen die Normalisierung des Hostnamens inaktivieren. Wenn Sie die Normalisierung des Hostnamens inaktivieren, werden der Hostname und die IP-Adressen unverändert verwendet. Verweise auf localhost werden normalerweise zur Loopback-Adresse 127.0.0.1 aufgelöst.

    JNDI-Clients können die Namenssyntax über eine Eigenschaft festlegen. Die Eigenschaftseinstellung wird von der Ausgangskontextfactory angewendet, wenn Sie ein neues java.naming.InitialContext-Objekt instanziieren.

    Verwenden Sie eines der folgenden Verfahren, um diese Eigenschaft zu definieren:
    • Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein. Beispiel:
      java -Dcom.ibm.websphere.naming.hostname.normalizer=...none...
    • Erstellen Sie eine Datei mit dem Namen jndi.properties als Textdatei mit den gewünschten Eigenschaftseinstellungen. Beispiel:
      ...
      com.ibm.websphere.naming.hostname.normalizer=...none...
      ...

      Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.hostname.normalizer definieren.

    • Sie können die Java-Konstanten PROPS.HOSTNAME_NORMALIZER* in einem Java-Programm verwenden. Diese Java-Konstanten werden in der Datei com.ibm.websphere.naming.PROPS definiert. Die folgenden Konstantendefinitionen werden verwendet, um anzugeben, ob Sie dieses Verfahren verwenden:
      public static final String HOSTNAME_NORMALIZER =
          "com.ibm.websphere.naming.hostname.normalizer";
      public static final String HOSTNAME_NORMALIZER_NONE = "...none...;

      Wenn Sie diese Definitionen in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu, und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:

      java.util.Hashtable env = new java.util.Hashtable();
      ...
      env.put(PROPS.HOSTNAME_NORMALIZER, PROPS.HOSTNAME_NORMALIZER_NONE);
          // Normalisierung des Hostnamens inaktivieren
      ...
      javax.naming.Context initialContext = new javax.naming.InitialContext(env);

    Beispiel: Normalisierung des Hostnamens inaktivieren

    Die Eigenschaft der Normalisierungsfunktion kann an den InitialContext-Konstruktor über den entsprechenden Parameter in den Systemeigenschaften oder in einer Datei jndi.properties übergeben werden. Der Ausgangskontext und alle Kontexte, die über diesen Ausgangskontext lokalisiert werden, verwenden diese Eigenschaftseinstellung.

    Das folgende Beispiel zeigt, wie Sie die Normalisierung des Hostnamens inaktivieren:

    ...
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    import com.ibm.websphere.naming.PROPS; // WebSphere-Naming-Konstanten
    ...
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, 
          "com.ibm.websphere.naming.WsnInitialContextFactory");
    env.put(Context.PROVIDER_URL, ...);
    env.put(PROPS.HOSTNAME_NORMALIZER, PROPS.HOSTNAME_NORMALIZER_NONE);
    Context initialContext = new InitialContext(env);
    java.lang.Object o = initialContext.lookup(...);
    ...

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tnam_develop_naming
Dateiname:tnam_develop_naming.html