Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Versionshinweise

- Previous: Kapitel 2 Info über Anwendungsserver Enterprise Edition 8.1 2005Q2

# Kapitel 3 Bekannte Probleme und Beschränkungen

In diesem Kapitel werden bekannte Probleme und die zugehörigen Abhilfemaßnahmen für die Software Sun Java System Anwendungsserver Enterprise Edition 8.1 2005Q2 erläutert. Wenn für ein Problem keine spezielle Plattform angegeben ist, betrifft es alle Plattformen. Die hier gegebenen Informationen sind wie folgt unterteilt:

- Administration

- Apache und Lastenausgleich-Plugin

- Anwendungsclient

- Im Lieferumfang enthaltene Sun JDBC-Treiber

- Konnektoren

- Dokumentation

- Hochverfügbarkeit

- Installation

- J2EE Tutorial

- Lifecycle-Verwaltung

- Protokollierung

- Message Queue

- Überwachung

- PointBase

- Beispiele

- Sicherheit

- Aufrüsten

- Webcontainer

# Administration

In diesem Abschnitt werden bekannte Verwaltungsprobleme sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6171458 | Das `package-appclient`-Skript wird nicht ausgeführt, wenn `domain1` nicht vorhanden ist. In `$INSTALL/lib/package-appclient.xml` ist standardmäßig ein hartkodierter Wert für die Variable `AS_ACC_CONFIG` für `domain1` festgelegt, auf den durch die Datei `asenv.conf` verwiesen wird. Wenn domain1 gelöscht und eine neue Domäne erstellt wird, wird die `AS_ACC_CONFIG`-Variable nicht entsprechend der neuen Domäne aktualisiert, sodass die Ausführung des `package-appclient`-Skripts fehlschlägt. Lösung Gehen Sie folgendermaßen vor: Entfernen Sie `domain1` nicht und erstellen Sie andere Domänen um diese Domäne. Entfernen Sie `domain1`, und ersetzen Sie den hartcodierten Wert für `domain1` in `$INSTALL/lib/package-appclient.xml` durch den neuen Domänennamen. Diesen Vorgang müssen Sie für jede neu erstellte Domäne durchführen, wenn `domain1` nicht mehr vorhanden ist.
6196993 | Gesicherte Domäne kann nicht unter einem anderen Namen wiederhergestellt werden. Eine Domäne kann in derselben Application Server-Installation nicht über die Befehle `backup-domain` und `restore-domain` gespiegelt werden, da die Domäne nicht unter Verwendung eines anderen Namens als dem ursprünglichen Namen wiederhergestellt werden kann (wenngleich der Befehl `asadmin restore-domain` eine Option zum Umbenennen der Domäne bietet). Die Umbenennung der gesicherten Domäne scheint erfolgreich, doch der Versuch, die umbenannte Domäne zu starten, schlägt fehl, da die Einträge in der Domänenkonfiguration nicht geändert werden und `startserv` und `stopserv` den ursprünglichen Domänennamen zum Festlegen von Pfaden verwenden. Lösung Der vom Befehl `restore-domain` verwendete Domänenname muss mit dem ursprünglichen, vom Befehl `backup-domain` verwendeten Domänennamen übereinstimmen. Die Befehle `backup-domain` und `restore-domain` in Application Server 8.1 funktionieren nur zum Sichern und Wiederherstellen derselben Domäne auf demselben Computer.
6200011 | Das Starten von Application Server mit zusätzlichem JMX-Agent wird nicht unterstützt. J2SE 1.4.x, 5.0 oder höher kann für die Ausführung mit Application Server konfiguriert werden. In J2SE 5.0 ermöglicht eine plattformeigene Funktion das Starten eines JMX-Agenten. Um diese Funktion zu aktivieren, setzen Sie die entsprechenden Systemeigenschaften für den Serverstart fest. Zu den möglichen Werten gehören:
    name="com.sun.management.jmxremote" value="true"
    name="com.sun.management.jmxremote.port" value="9999"
    name="com.sun.management.jmxremote.authenticate" value="false"
    name="com.sun.management.jmxremote.ssl" value="false"
Nachdem Sie die JMX-Eigenschaften konfiguriert und den Server gestartet haben, wird ein neuer `jmx-connector`-Server in der Virtual Machine von Application Server gestartet. Ein unerwünschter Nebeneffekt davon besteht darin, dass die Administrationsfunktionen beeinträchtigt werden und die Application Server-Administrationskonsole und Befehlszeilenschnittstelle evtl. unerwünschte Ergebnisse produzieren. Dieses Problem wird durch Konflikte zwischen dem integrierten `jmx-connector`-Server und dem neuen `jmx-connector`-Server verursacht. Lösung Wenn Sie `jconsole` (oder einen anderen `JMX-kompatiblen` Client) verwenden, können Sie den standardmäßig beim Start von Application Server gestarteten JMX-Konnektor-Server wiederverwenden. Wird der Server gestartet, wird eine Zeile ähnlich der unten dargestellten Zeile auf dem Server angezeigt.Protokoll. Sie können eine Verbindung zur dort angegebenen `JMXService`-URL herstellen und dieselben Management-/Konfigurationsoperationen durchführen, nachdem Sie die Anmeldeinformationen erfolgreich angegeben haben, beispielsweise:
    [#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|
    javax.enterprise.system.tools.admin|_ThreadID=10;|ADM1501:
    Dies ist die JMXServiceURL für JMXConnectorServer:
    [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
    rmi-jmx-connector]. Dieser URL gilt für die entfernten
    administrativen Clients, die die JSR 160 JMX-Konnektoren verwenden.|#]
Weitere Informationen finden Sie im Administration Guide.
6206176 | Unter UNIX sind Berechtigungen für das Ausführen der Application Server start -und stop-Skripten zu restriktiv. Wenn Sie als Benutzer "A" angemeldet sind und den Befehl `asadmin restore-domain` ausführen, wird in den Skripts die Berechtigung 744 (`rwxr--r--`) festgelegt. Wenn Sie anschließend als Benutzer "B" angemeldet sind, können Sie keine Domäne starten oder beenden (selbst wenn Benutzer "B" Root ist), da die Skripts nur noch von Benutzer "A" ausgeführt werden können. Lösung Ändern Sie die Berechtigungen in den Skripts:
    chmod 755 appserv/domains/domain-name/bin/*
1. 6236544, 6275436 | Lastenausgleichs-Konfigurationsdatei kann nicht mit dem Endpunkt-URL eines Webservice erstellt werden. Beim Einrichten der Lastenausgleichskonfiguration mit einer Anwendung, die über ein EJB-Modul verfügt und eine Webservice-URL exportiert, befindet sich das Kontext-Stammverzeichnis (root) für den Webservice nicht in der resultierenden Datei `loadbalancer.xml`. Lösung Bearbeiten Sie die Datei `loadbalancer.xml` wie folgt, um das fehlende Webmodul hinzuzufügen:
       <web-module context-root="context-root-name"
       disable-timeout-in-minutes="30" enabled="true"/>
Ersetzen Sie den Wert context-root-name mit dem Kontext-Rootnamen des Webservice, der als EJB offengelegt wurde.
6288893 | Anwendungsserver-Neustart unter Verwendung von `sun-appserv-admin` führt zu einem `LoginException`-Fehler. Lösung Benennen Sie das vorhandene <as_install>`/bin/asant`-Skript in `asant.bak` um. Kopieren Sie die Datei `asant.template` in <as_install> `/lib/install/templates/ee` (für die SE/EE-Version) in das <as_install>`/bin`/-Verzeichnis und benennen Sie die Datei in `asant` um. Bearbeiten Sie das gerade kopierte <as_install>`/bin/asant`-Skript, wobei Sie das `%CONFIG_HOME%`-Token durch <as_install>`/config` ersetzen. Falls manuelle Änderungen an der ursprünglichen `asant.bak`-Datei vorgenommen wurden, führen Sie diese in das neue `asant`-Skript zusammen.
6315957 | Die Datei `.asadmintruststore` wird in der Anwendungsserver-Dokumentation nicht beschrieben. Falls diese Datei nicht im `home`-Verzeichnis des Serveradministrators vorhanden ist, können schwerwiegende Fehler beim Upgrade bestimmter, auf dem Server gehosteter Anwendungen auftreten. Lösung Falls möglich, sollte der Befehl `asadmin start-domain domain1` von dem Benutzer ausgeführt werden, der den Server installierte. Falls er nicht von diesem Benutzer ausgeführt wird, sollte `.asadmintruststore` aus dem `home`-Verzeichnis des installierenden Benutzers in das `home`-Verzeichnis des ausführenden Benutzers kopiert werden. Beachten Sie Folgendes: Falls die Datei aus dem `home`-Verzeichnis des installierenden Benutzers in das `home`-Verzeichnis des ausführenden Benutzers verschoben (nicht kopiert) wird, treten eventuell Probleme beim Anwendungsupgrade auf, wie in den Bugs 6309079, 6310428 und 6312869 beschrieben, da der Upgrade-/Installationsbenutzer (in Java ES in der Regel `root`) in seinem Stammverzeichnis nicht mehr über die Datei `.asadminstruststore` verfügt.
6407140 | Serverinstanzen, die mit dem `start-node-agent` gestartet wurden, verfügen nicht über die aktuellen Synchronisationsinhalte. Der Befehl für den `asadmin start-node-agent` startet automatisch die Remote Server-Instanzen ohne Snychronisation mit DAS. Lösung Wenn Sie eine Remote Server-Instanz starten, die mit dem zentralen, von DAS verwalteten Repository synchronisiert ist, müssen Sie die Option `--startinstances=false` mit dem Befehl `asadmin start-node-agent` angeben. Verwenden Sie dann den Befehl `asadmin start-instance`, um die Remote Server-Instanz zu starten
6654726 | Die Funktion der Administrationskonsole zur Auswahl der Verschlüsselungsfolgen funktioniert nicht ordungsgemäß. Wenn Sie die HTTP-Zielgeräte "Alle Verschlüsselungsfolgen unterstützenâ auswählen, sind die Kontrollkästchen deaktiviert, werden jedoch beim Aktualisieren der Seite aktiviert, auch wenn das Kontrollkästchen "Alle unterstützen..." aktiviert ist. Dies scheint zwar ein Problem zu sein, die Änderungen werden der Konfiguration jedoch hinzugefügt, wenn ein Zertifikatspseudonym eingegeben und auf 'Speichern' geklickt wurde. Lösung Kein Handeln erforderlich. Die Änderungen wurden gespeichert.

# Apache und Lastenausgleich-Plugin

In diesem Abschnitt werden bekannte Probleme des Apache Webservers und des Lastenausgleich-Plugins sowie zugehörige Lösungen erläutert.

Bug-ID | Zusammenfassung
--- | ---
6306784 | Der High Availability Administration Guide enthält falsche Anweisungen zur Verwendung von `openssl` mit Apache. Lösung Führen Sie beim Kompilieren und Erstellen von `openssl` folgende Befehle aus: `cd openssl-0.9.7e` `config` `make` Außerdem variiert bei Apache 1.3 der Verzeichnisname der `mod_ssl`-Quelle je nach verwendeter Apache-Version. Beispielsweise lautet bei Apache 1.3.33 der Name `mod_ssl-2.8.22-1.3.33`.
6307976 | Im High Availability Administration Guide sind keine Anweisungen zur Verwendung eines Zertifikats für Apache 2.0 enthalten. Lösung Zum Ausführen der Apache-Sicherheit müssen Sie ein Zertifikat verwenden. Anweisungen, wie Sie von einer Zertifizierungsstelle ein Zertifikat erhalten, finden Sie in den Informationen über Zertifikate unter modssl FAQ.
6308021 | Apache Web Server muss als Root gestartet werden. Lösung Wenn Ihr Anwendungsserver unter Solaris unter Root installiert wurde, müssen Sie Apache Web Server als Root starten. Java Enterprise System-Installationen werden als Root installiert. Für Apache 2.0 gilt Folgendes: Nach dem Start als Root kann Apache umgeschaltet und als ein anderer von Ihnen festgelegter Benutzer ausgeführt werden. Diesen Benutzer legen Sie in der Datei `/conf/httpd.conf` fest. Zum Start als Root müssen Sie auf vielen Systemen die Datei `httpd.conf` bearbeiten, um die korrekte Gruppe anzugeben. Ersetzen Sie folgende Zeile: `Group #-1` durch `Group nobody` Weitere Informationen zur Benutzer-/Gruppenverwendung finden Sie in der Datei `httpd.conf`.
6308043 | Zusatz zu den Anweisungen für die Verwendung von `openssl` mit Apache Web Server 2.0 unter Solaris. Nach Installation von Apache 2.0 und des Lastenausgleich-Plugins bearbeiten Sie `ssl.conf` und `sll-std.conf` wie folgt: Ersetzen Sie folgende Zeile: `<VirtualHost _default_:9191>` durch `<VirtualHost machine_name:9191>` Dabei ist machine_name der Name Ihres Computers und `9191` die Sicherheits-Portnummer.

# Anwendungsclient

In diesem Abschnitt werden bekannte Probleme des Anwendungsclients sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6193556 | JAR-Bibliothek im Archiv des Anwendungsclients überschreibt die MANIFEST-Datei. Wenn Sie in Ihrer Client-JAR über eine JAR-Datei auf oberster Ebene verfügen (in diesem Fall reporter.jar) und den Client JAR bereitstellen, überschreibt die Datei MANIFEST für diese JAR die Datei MANIFEST für den Client-JAR. Lösung Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.
6373043 | Technologien für dynamische Inhalte, wie beispielsweise CGI-bin und SHTML, werden nicht mehr unterstützt. Lösung Verwenden Sie stattdessen JSP- und Webservice-Technologien.

# Im Lieferumfang enthaltene Sun JDBC-Treiber

In diesem Abschnitt werden bekannte Probleme der im Lieferumfang enthaltenen Sun JDBC-Treiber sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6165970 | Anwendungen, die die `TRANSACTION_SERIALIZABLE`-Isolationsebene zusammen mit dem im Paket enthaltenen Sun-Treiber für Microsoft SQL Server verwenden, hängen, wenn eine vorbereitete Aktualisierungsanweisung verwendet wird, die einsetzt, wenn zwei Transaktionen parallel ausgeführt werden und eine der Transaktionen rückgängig gemacht wird. Um die Isolationsebene für eine Verbindung wie gewünscht setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Einzelheiten zur Konfiguration von Verbindungspools finden Sie im Administration Guide. Lösung Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.
6170432 | `PreparedStatement`-Fehler. Beschreibung 1 Wenn eine Anwendung mehr als 3000 `PreparedStatement`-Objekte in einer Transaktion generiert, kann folgender DB2-Fehler auftreten: `[sunm][DB2 JDBC Driver] No more available statements.``Erstellen Sie Ihr Paket mit einem höheren dynamicSections-Wert neu.` Lösung 1 Fügen Sie die folgenden Eigenschaften zur Verbindungspooldefinition hinzu, damit der Treiber DB2-Pakete mit einem größeren dynamischen Abschnittswert neu bindet: createDefaultPackage=true replacePackage=true dynamicSections=1000 Einzelheiten zur Konfiguration von Verbindungspools finden Sie im Administration Guide. Beschreibung 2 Im Zusammenhang mit dem oben erwähnten `PrepardStatement`-Fehler kann folgender Fehler auftreten: `[sunm][DB2 JDBC Driver][DB2]Virtueller Speicher oder Datenbankressource steht nicht zur Verfügung.` Lösung 2 Erhöhen Sie den Wert des Konfigurationsparameters APPLHEAPSZ des DB2-Servers. Ein geeigneter Wert ist 4096. Beschreibung 3 Isolationsebene `TRANSACTION_SERIALIZABLE` Wenn eine Anwendung die Isolationsebene `TRANSACTION_SERIALIZABLE` und einen der oben genannten Parameter verwendet, kann die Anwendung beim Verbindungsaufbau abstürzen. Lösung 3 Um die Isolationsebene für eine Verbindung wie gewünscht setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Anweisungen dazu finden Sie im Administration Guide.
6189199 | Probleme beim Einrichten der Isolationsebene mit dem im Paket gelieferten Sun-Treiber für Sybase Adaptive Server. Anwendungen, die die `TRANSACTION_SERIALIZABLE`-Isolationsebene zusammen mit dem im Paket enthaltenen Sun-Treiber für Sybase Adaptive Server verwenden, hängen, wenn eine vorbereitete Aktualisierungsanweisung verwendet wird, die einsetzt, wenn zwei Transaktionen parallel ausgeführt werden und eine der Transaktionen rückgängig gemacht wird. Der Rollback der Verbindungen schlägt fehl und folgende Meldung wird angezeigt. Die Verbindungen, für die das Rollback durchgeführt werden sollte, können nicht mehr verwendet werden. `java.``sql.``SQL-Ausnahmefehler:` `[sunm][Sybase JDBC Driver]Request cannot be submitted due to wire contention` Die `TRANSACTION_REPEATABLE_READ`-Isolationsebene wird von Sybase Adaptive Server nicht unterstützt. Beim Abfragen von `DatabaseMetaData` gibt der Sun-Treiber jedoch an, dass diese Isolationsebene von der Datenbank unterstützt wird. Die Ausführung der Anwendungen, die diese Isolationsebene verwenden, schlägt fehl. Anwendungen, die den mitgelieferten Sun-Treiber verwenden, können die Isolationsebene `TRANSACTION_READ_UNCOMMITTED` nicht festlegen. Beim Zugreifen auf `DataBaseMetaData` gibt die Anwendung folgenden Ausnahmefehler aus: `java.``sql.``SQL-Ausnahmefehler:` `[sunm][Sybase JDBC Driver][Sybase]Das Optimierungswerkzeug (Optimizer) konnte keinen eindeutigen Index finden, der für das Durchführen einer Suche auf Isolationsebene 0 in Tabelle 'sybsystemprocs verwendet werden könnte.``dbo.``spt_server_info'.` Lösung Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.
6247468 | Unter Solaris 10 und Enterprise Linux 3.0 lässt der im Sun-Paket enthaltene Oracle JDBC-Treiber keine Verbindungserstellung zu. Lösung Setzen Sie die folgende Eigenschaft im JDBC-Verbindungspool, wenn Sie die SUN JDBC-Oracle-Datenquelle verwenden (`com.sun` `sql.``jdbcx.oracle.``OracleDataSource`): `<property name="serverType" value="dedicated"/>` Der Wert der Eigenschaft hängt davon ab, wie der Listener des Oracle-Servers konfiguriert ist. Wenn er im Modus "shared" konfiguriert ist, muss der obige Wert zu "dedicated" geändert werden.
6554602 | Wenn sich beim Start mit JDBC 10.2-Treibern mehr als eine JDBC JAR-Datei in `CLASSPATH` befindet, kann dies zu folgender Ausnahme führen: `java.lang.SecurityException: Sealing violation exception`. Genaue Erläuterungen von Oracle finden Sie in der folgenden Oracle Document ID:
    Hinweis: 405446
    Betreff: JDBC-Treiber 10.2 verwendet versiegelte JAR-Dateien und kann zu
    der Sicherheitsausnahme einer Siegelverletzung führen.
Lösung (Vorschlag von Oracle) Stellen Sie sicher, dass der `CLASSPATH` nur eine JDBC-Treiber-JAR-Datei enthält.

# Konnektoren

In diesem Abschnitt werden bekannte Probleme der J2EE-Konnektorenarchitektur und die zugehörigen Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6188343 | Nach dem Neustart einer DAS-Instanz kann die Bereitstellung des Konnektormoduls nicht aufgehoben werden, wenn die Option cascade auf false gesetzt ist. Dieses Problem tritt auf, wenn ein eigenständiges oder eingebettetes Konnektormodul in DAS und in Konnektor-Verbindungspools bereitgestellt ist und Ressourcen für das bereitgestellte Modul erstellt werden. Nach dem Neustart der DAS-Instanz schlägt die Aufhebung der Bereitstellung im Konnektormodul fehl, wenn cascade auf false gesetzt ist. Folgender Ausnahmefehler tritt auf: `[#|2004-10-31T19:``52:23.049-0800|INFO|sun-appserver-ee8.1|javax.``enterprise.system .core|_ThreadID=14;|CORE5023:` `Fehler beim Entladen der Anwendung [foo]|#].` Lösung Setzen Sie die cascade-Option auf true, um nach dem Neustart der DAS-Instanz die Bereitstellung der eigenständigen und eingebetteten Konnektoren aufheben zu können.

# Dokumentation

In diesem Abschnitt werden die bekannten Probleme mit der Dokumentation sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
Verschiedene IDs | Javadoc-Unstimmigkeiten. Die Javadoc verschiedener AMX-Schnittstellen und -Methoden fehlen oder sind nicht korrekt: Die Getter-Methoden für die Statistiken `NumConnAcquired` und `NumConnReleased` fehlen in `ConnectorConnectionPoolStats` und `AltJDBCConnectionPoolStats`. Diese Getter-Methoden werden in zukünftigen Versionen als `getNumConnAcquired()` und `getNumConnReleased()` hinzugefügt. Der Aufruf folgender Methoden in `EJBCacheStats` verursacht einen Ausnahmefehler: `getPassivationSuccesses()`, `getExpiredSessionsRemoved()`, `getPassivationErrors()`, `getPassivations()`. Dieses Problem wird in zukünftigen Versionen behoben. Nach dem Starten des Servers vergehen einige Sekunden, bis alle AMX Mbeans registriert und verfügbar gemacht sind. In zukünftigen Versionen wird es möglich sein, festzustellen, wann die AMX-Beans vollständig geladen sind. Die Konstante `XTypes.``CONNNECTOR_CONNECTION_POOL_MONITOR` ist falsch geschrieben (`"NNN"`). Dieser Fehler wird in zukünftigen Versionen behoben.
6265624 | Paket-ANT gibt `java.lang` aus.`NoClassDefFoundError`. Der folgende Ausnahmefehler tritt im Thread "main" auf: `java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher`. Lösung Die Verwendung der Paket-ANT für Funktionen außerhalb von Anwendungsserver wird nicht empfohlen.
6486123 | Die Dokumentation zur Herstellung einer physischen Verbindung von einer umschlossenen Verbindung ist nicht mehr korrekt. Aufgrund anderer Fehler (vermutlich 6295215) ist der im Abschnitt Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide, Kapitel 11, Using the JDBC API for Database Access in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide angegebene Code nicht korrekt. Insbesondere sollte die folgende Zeile:
    Connection drivercon = ds.getConnection(con);
nun wie folgt lauten:
    Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

# Hochverfügbarkeit

In diesem Abschnitt werden bekannte Probleme mit der Hochverfügbarkeits-Datenbank (HADB) und zugehörige Lösungen erläutert.

Bug-ID | Zusammenfassung
--- | ---
keine ID | HADB-Konfiguration mit Doppelnetzwerken. Unter Solaris SPARC ist eine HADB-Konfiguration für zwei Netzwerke in zwei Teilnetzen problemlos möglich. Auf Solaris x86- und Linux-Plattformen führen jedoch Betriebssystem- bzw. Netzwerktreiberprobleme dazu, dass eine doppelte Netzwerkkonfiguration nicht immer einwandfrei ausgeführt wird. Dadurch entstehen folgende HADB-Probleme: Unter Linux werden bei der Meldungsübermittlung einige der HADB-Prozesse blockiert. Dadurch werden HADB-Knoten neu gestartet und eine Netzwerkpartitionierung durchgeführt. Unter Solaris x86 führt ein Netzwerkfehler dazu, dass nicht auf die andere Netzwerkschnittstelle gewechselt werden kann. Da dies nicht andauernd passiert, ist es immer noch besser, anstelle nur eines Netzwerks zwei Netzwerke zu haben. Diese Probleme sind in Solaris 10 teilweise gelöst. Abschneiden wird nicht unterstützt. HADB unterstützt keine doppelte Netzwerkkonfiguration unter Windows 2003 (Nr. 5103186).
keine ID | Die Erstellung der HADB-Datenbank schlägt fehl. Die Erstellung einer neuen Datenbank kann fehlschlagen und folgenden Fehler ausgeben, der besagt, dass zu wenig gemeinsame Speichersegmente verfügbar sind: `HADB-E-21054:` `Systemressource nicht verfügbar:` `HADB-S-05512:` `Anhängen des gemeinsamen Speichersegments mit Schlüssel "xxxxx" fehlgeschlagen, OS-Status=24 OS-Fehlermeldung:` `Zu viele Dateien geöffnet.` Lösung Stellen Sie sicher, dass der gemeinsame Speicher konfiguriert wurde und die Konfiguration funktioniert. Prüfen Sie insbesondere unter Solaris 8 die Datei `/etc/system` und stellen Sie sicher, dass der Wert der Variable `shmsys:``shminfo_shmseg` mindestens die sechsfache Anzahl der Knoten pro Host beträgt.
5052548 | Gemeinsam verwendete Arbeitsspeichersegmente gesperrt und können nicht ausgelagert werden. HADB 4.3-0.16 und höher ist für die Verwendung von beim Erstellen und Anfügen von gemeinsam verwendeten Arbeitsspeichersegmenten konfiguriert (verwendet das Flag `SHM_SHARE_MMU` ). Die Verwendung dieses Flag hat als wesentliche Wirkung, dass die gemeinsam verwendeten Arbeitsspeichersegmente im physischen Speicher gesperrt werden und nicht ausgelagert werden können. Die kann bei Installationen auf weniger leistungsstarken Computern schnell zu Problemen führen. Wenn also einem Entwickler ein Computer mit 512 MB Arbeitsspeicher und einem recht großen Auslagerungbereich bei Verwendung von Anwendungsserver7.0 EE zur Verfügung steht, und 7.1 EE oder höher installiert wird, treten Probleme bei der Konfiguration des Standardclusters `clsetup` auf. Dieses erstellt zwei HADB-Knoten, jeweils mit einer `devicesize` von `512`, was dazu führt, dass nicht genügend physischer RAM zur Verfügung steht, um den gemeinsamen Speicher zu unterstützen, die beide Knoten benötigen. Lösung Stellen Sie sicher, dass Sie über Arbeitsspeicher im empfohlenen Umfang verfügen, wenn Sie Application Server und HADB auf demselben Rechner installieren. Weitere Informationen finden Sie unter HADB-Anforderungen und unterstützte Plattformen.
5091280 | `hadbm set` prüft Ressourcenverfügbarkeit nicht (Festplatte und Arbeitsspeicher). Das Verwaltungssystem prüft beim Erstellen von Datenbanken und beim Hinzufügen von Knoten die Ressourcenverfügbarkeit. Die Verfügbarkeit der Ressourcen wird jedoch nicht geprüft, wenn mit `hadbm set` die Puffergröße des Geräts oder des Hauptspeichers geändert wird. Lösung Stellen Sie sicher, dass auf allen Hosts genügend freier Festplatten-/Arbeitsspeicher zur Verfügung steht, bevor Sie die Konfigurationsattribute `devicesize` bzw. `buffersize` erhöhen.
5091349 | Heterogene Pfadangaben für `packagepath` werden nicht unterstützt. Es ist nicht möglich, ein und dasselbe Software-Paket unter demselben Namen in verschiedenen Pfaden auf unterschiedlichen Hosts zu registrieren, zum Beispiel:
    hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
    Paket erfolgreich registriert.
    hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
    hadbm:Fehler 22171: Ein Software-Paket wurde bereits unter dem Paketnamen
    test registriert.
Lösung HADB unterstützt keine heterogenen Pfade für Knoten eines Datenbank-Clusters. Stellen Sie sicher, dass das Installationsverzeichnis des HADB-Servers (`--packagepath`) auf allen teilnehmenden Hosts identisch ist.
6173886, 6253132 | `createdomain` schlägt u. U. fehl. Wenn der Management-Agent auf einem Host mit mehreren Netzwerkschnittstellen ausgeführt wird, kann der Befehl createdomain fehlschlagen, wenn sich nicht alle Netzwerkschnittstellen im selben Teilnetz befinden:
    hadbm:Fehler 22020: Die Management-Agents konnten keine
    Domäne herstellen. Prüfen Sie, ob die Hosts mit UDP Multicast
    kommunizieren können.
Die Management-Agenten verwenden (falls nicht anders konfiguriert) die "erste" Schnittstelle für UDP-Multicasts (die "erste" gemäß Definition durch das Ergebnis von `java.net.``NetworkInterface.getNetworkInterfaces()` ). Lösung Die beste Lösung besteht darin, dem Management-Agenten vorzuschreiben, welches Teilnetz er verwenden soll (setzen Sie `ma.server.mainternal.interfaces` in der Konfigurationsdatei, z. B. `ma.server.mainternal.interfaces=10.11.100.0`). Alternativ kann der Router zwischen den Teilnetzen so konfiguriert werden, dass er Multicast-Pakete weiterleitet (der Management-Agent verwendet die Multicast-Adresse 228.8.8.8). Bevor Sie einen Versuch mit einer neuen Konfiguration der Management-Agenten unternehmen, müssen Sie eventuell die Management-Agent-Repository bereinigen. Beenden Sie alle Agenten in der Domäne und löschen Sie alle Dateien und Verzeichnisse im Repository-Verzeichnis (wird durch `repository.``dr.path` in der Konfigurationsdatei des Management-Agenten identifiziert). Dies muss auf allen Hosts durchgeführt werden, bevor die Agenten mit einer neuen Konfigurationsdatei erneut gestartet werden.
6190878 | Verzeichnisse müssen nach dem Löschen einer HADB-Instanz bereinigt werden. Nach dem Löschen einer HADB-Instanz schlagen spätere Versuche, neue Instanzen mit dem Befehl `configure-ha-cluster` zu erstellen, fehl. Das Problem besteht darin, dass alte Verzeichnisse aus der ursprünglichen HADB-Instanz in `ha_install_dir/rep/*` und `ha_install_dir/config/hadb/``instance_name` übrig bleiben. Lösung Achten Sie darauf, diese Verzeichnisse nach dem Löschen einer HADB-Instanz ebenfalls zu löschen.
6230792, 6230415 | Das Starten, Stoppen und erneute Konfigurieren der HADB kann fehlschlagen oder nicht mehr reagieren. Unter Solaris 10 Opteron kann das Starten, Stoppen und erneute Konfigurieren der HADB mit dem Befehl `hadbm` fehlschlagen oder das System nicht mehr reagieren, wobei einer der folgenden Fehler ausgegeben wird:
    hadbm:Fehler 22009: Der ausgegebene Befehl erzielte in den letzten
    300 Sekunden keinen Fortschritt.
    HADB-E-21070: Der Vorgang konnte innerhalb des Zeitlimits nicht abgeschlossen
    werden, wurde jedoch nicht abgebrochen und wird eventuell zu einem späteren
    Zeitpunkt abgeschlossen.
Dies tritt u. U. auf, wenn es Unstimmigkeiten hinsichtlich des Lesens/Schreibens in eine Datei (`nomandevice`) gibt, die vom Prozess `clu_noman_srv` verwendet wird. Dieses Problem kann erkannt werden, indem in den HADB-Protokolldateien nach den folgenden Meldungen gesucht wird:
    n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3
    733 reagiert nicht.
    n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Keine Reaktion von ihm in
    104.537454 Sek.
    n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3
    733 wurde nicht gestartet.
Lösung Die folgende Problemlösung wurde noch nicht verifiziert, da das Problem noch nicht manuell reproduziert wurde. Jedoch sollte durch Ausführung dieses Befehls für den betroffenen Knoten das Problem gelöst werden.
    hadbm restartnode --level=clear nodeno dbname
Beachten Sie, dass alle Geräte für den Knoten neu initialisiert werden. Eventuell müssen Sie den Knoten stoppen, bevor Sie ihn neu initialisieren.
6232140 | Der Management-Agent wird mit dem Ausnahmefehler `"IPV6_MULTICAST_IF fehlgeschlagen"` beendet. Beim Start auf einem Host, auf dem Solaris 8 ausgeführt wird und verschiedene NIC-Karten installiert sind, kann es passieren, dass bei Vorhandensein einer Mischung von Karten mit aktiviertem IPv6 und IPv4 der Management-Agent beendet wird und der Ausnahmefehler `"IPV6_MULTICAST_IF fehlgeschlagen"` auftritt.`"` Lösung Legen Sie die Umgebungsvariable `JAVA_OPTIONS` auf `-Djava.net.preferIPv4Stack=true` fest; zum Beispiel:
    export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"
Alternativ verwenden Sie Solaris 9 oder höher. Dort tritt dieses Problem nicht auf.
6249685 | `clu_trans_srv` kann nicht unterbrochen werden. In der 64-Bit-Version von Red Hat Enterprise Linux 3.0 gibt es einen Bug, der dazu führt, dass der Prozess `clu_trans_srv` in einem Modus endet, der nicht unterbrochen werden kann, wenn asynchrones I/O ausgeführt wird. Das bedeutet, dass der Befehl kill -9 nicht funktioniert und das Betriebssystem neu gebootet werden muss. Lösung Verwenden Sie eine 32-Bit-Version von Red Hat Enterprise Linux 3.0.
6262824 | `hadbm` unterstützt keine Passwörter, die Großbuchstaben enthalten. Großbuchstaben in Passwörtern werden in Kleinbuchstaben umgewandelt, wenn das Passwort in `hadb` gespeichert wird. Lösung Verwenden Sie keine Passwörter, die Großbuchstaben enthalten.
6265419 | Beim Downgrading von HADB-Version 4.4.2.5 auf HADB-Version 4.4.1.7 schlägt M-A mit verschiedenen Fehlercodes fehl. Beim Downgrading auf eine vorherige HADB-Version kann der Management-Agent mit verschiedenen Fehlercodes fehlschlagen. Lösung Es ist zwar möglich, einen Downgrade der HADB-Datenbank auszuführen, jedoch kann kein Downgrade für den Management-Agent ausgeführt werden, wenn Änderungen an den Repository-Objekten vorgenommen wurden. Nach einem Downgrade müssen Sie weiter den Management-Agent von der letzten HADB-Version verwenden.
6271063 | Installation/Deinstallation und `symlink`-Erhaltung. Hinsichtlich der Installation/Deinstallation des HADB c-Pakets (Solaris: `SUNWhadbc`, Linux: `sun-hadb-c`) Version <m.n.u-p> wird `symlink /opt/SUNWhadb/<m>` niemals angefasst, sobald sie existiert. Daher ist es möglich, dass eine verwaiste `symlink` vorhanden ist. Lösung Löschen Sie `symlink` vor der Installation oder nach der Deinstallation; es sei denn, die Datei wird verwendet.
6273681 | Management-Agenten in globalen und lokalen Zonen können stören. Unter Solaris 10 wird durch Stoppen eines Management-Agenten mittels Verwendung des ma-initd-Skripts in einer globalen Zone der Management-Agent in der lokalen Zone ebenfalls angehalten. Lösung Installieren Sie den Management-Agent nicht sowohl in der globalen als auch der lokalen Zone.
6275103 | `hadbm/ma` sollte eine bessere Fehlermeldung ausgeben, wenn ein Sitzungsobjekt die Zeitsperre überschritten hat und bei M-A gelöscht wurde. Mitunter kann es durch einen Ressourcenkonflikt auf dem Server dazu kommen, dass der Management-Client getrennt wird. Bei der erneuten Verbindungsherstellung wird u. U. eine irreführende Fehlermeldung `"hadbm:``Fehler 22184:` `Zum Herstellen der Verbindung mit dem Management-Agenten ist ein Passwort erforderlich"` zurückgegeben. Lösung Prüfen Sie, ob ein Ressourcenproblem auf dem Server vorliegt, ergreifen Sie geeignete Maßnahmen (z. B. fügen Sie weitere Ressourcen hinzu) und führen Sie den Vorgang erneut aus.
6275319 | Von Root verschiedene Benutzer können HADB nicht verwalten. Die Installation mit Java Enterprise System (als Root) gibt von Root verschiedenen Benutzern keine Benutzerrechte zum Verwalten von HADB. Lösung Melden Sie sich immer als Root an, um HADB zu verwalten.
6293912 | Der Management-Agent sollte keine besonderen Schnittstellen verwenden. Schnittstellen für besondere Zwecke mit IP-Adressen wie `0.0.0.0` sollten nicht als gültige Schnittstellen registriert werden, die für HADB-Knoten im Management-Agenten verwendet werden. Die Registrierung solcher Schnittstellen kann zu Problemen führen, wenn an diesen Schnittstellen HADB-Knoten eingerichtet werden, indem ein Benutzer einen `hadbm create`-Befehl mithilfe von Hostnamen anstelle von IP-Adressen aufruft. Die Knoten können dann nicht kommunizieren und führen dazu, dass der `create`-Befehl hängt. Lösung Wenn Sie `hadbm create` auf Hosts mit mehreren Schnittstellen verwenden, müssen Sie immer die IP-Adressen angeben, die ausdrücklich die DDN-Notation verwenden.
6291562 | Unter Windows schlägt die Reassemblierung fehl. Auf der Windows-Plattform kann es bei bestimmten Konfigurationen zu einer großen Anzahl von Reassemblierungsfehlern im Betriebssystem kommen. Das Problem trat bei Konfigurationen von mehr als zwanzig Knoten auf, als mehrere Tabellenscans (`select *`) gleichzeitig ausgeführt wurden. Symptome können sein, dass die Transaktionen häufig abbrechen, die Reparatur oder Wiederherstellung lange Zeit in Anspruch nehmen kann und es zu häufigen Zeitüberschreitungen an verschiedenen Stellen im System kommt. Lösung Um das Problem zu beheben, kann die Windows-Registrierungsvariable `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters` auf einen Wert festgelegt werden, der höher ist als der Standardwert `100`. Es wird empfohlen, diesen Wert auf `0x1000` (`4096`) zu erhöhen. Weitere Informationen finden Sie unter. Artikel 811003 der Microsoft-Supportseiten.
6303581, 6346059, 6307497 | Beim Ausführen von `hadbm start` `<db_name>`, wird ein Teil des eingegebenen Passworts unmaskiert angezeigt. Wenn ein Rechner stark ausgelastet ist, kann es vorkommen, dass der Maskierungsmechanismus versagt, und einige Zeichen des eingegebenen Passworts sichtbar sind. Dies stellt ein gewisses Sicherheitsrisiko dar und das Passwort sollte stets maskiert sein. Lösung Legen Sie die Passwörter in eigenen Passwortdateien ab (die normalerweise seit Anwendungsserver 8.1 empfohlene Methode) und beziehen Sie sich darauf mit den Optionen `--adminpassword` bzw. `--dbpasswordfile`.

# Installation

In diesem Abschnitt werden die bekannten Installationsprobleme sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
5009728 | Unter manchen Linux-Systemen hängt die Fertigstellung der Installation nach Klicken auf die Schaltfläche "Fertig stellen". Dieses Problem wurde unter verschiedenen Linux-Systemen festgestellt. Am häufigsten kommt das Problem auf Java Desktop System 2 vor. Es wurde jedoch auch bei Distributionen von Linux Red Hat beobachtet. Nachdem Sie im letzten Fenster des Installationsprogramms auf die Schaltfläche "Fertig stellen" geklickt haben, schlägt der Versuch des Installationsprogramms fehl, die Seite Info bzw. die Seite zur Produktregistrierung im Browser anzuzeigen. Das Programm reagiert nicht mehr und zeigt keine Befehlseingabeaufforderung an. Lösung Beenden Sie den Installer durch Drücken von `Strg+C` im Terminalfenster, in dem der Installer gestartet wurde. Danach wird manchmal ein Browser-Fenster mit einer Produktinfo-Seite oder einer Registrierungsseite angezeigt. Sollte diese Seite nicht angezeigt werden, starten Sie den Browser und geben die folgende URL ein, um die Infoseite anzuzeigen:
    file://Installationsverzeichnis/docs-ee/about.html
Wenn Sie auch noch die Installationsoption zum Registrieren des Produkts gewählt haben, folgen Sie dem Link der Registrierungsseite, der sich auf der Produktinfo-Seite befindet.
1. 6199697 | Unter Windows muss bei der Installation das imq-Verzeichnis erstellt werden. Unter Windows schlägt der Message Queue-Boker unmittelbar nach der Installation von Application Server Enterprise Edition beim Starten fehl. Es wird eine Meldung angezeigt, die darauf hinweist, dass das Verzeichnis `drive:\as\domains\domain1\imq` nicht existiert. Beachten Sie, dass das Problem nicht auftritt, wenn der Broker nach dem Start von `domain1` gestartet wird. In diesem Fall wird das Verzeichnis nach dem Start des Brokers von Application Server erstellt. Lösung Erstellen Sie `var_home_dir_location`, bevor Sie den Broker erstellen.
       $imqbrokerd -varhome var_home_dir_location
   Beispiel:
       $imqbrokerd -varhome D:\as\domains\domain1\imq
6297837 | Das Installationsprogramm von Anwendungsserver zeigt das falsche Produktfreigabedatum im Produktnamen an, Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q4.” Lösung Der richtige Produktname/das richtige Datum sollte “Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q2” lauten.”
6396045 | Anwendungsserver unterstützt das Netzwerkdateisystem nicht (NFS). Lösung Keine.

# J2EE Tutorial

Zum Ausführen von J2EE 1.4 Tutorial auf Sun Java System Anwendungsserver Enterprise Edition 8.1 2005Q2 führen Sie folgende Schritte aus:

- Wenn Sie die Beispieldatei `/common/build.properties` wie in Kapitel “About this Tutorial” Abschnitt “About the Examples” bearbeiten, ändern Sie den Port 4848 in Port 4849.

- Bei Verwendung des Bereitstellungwerkzeugs (Deploytool) fügen Sie den Server `localhost:4849` hinzu, bevor Sie ein Beispiel bereitstellen.

- Bei Verwendung von Administration Console zum Erstellen von Ressourcen geben Sie auf der Registerkarte "Targets" den Server als Ziel an. Wenn Sie die Befehlszeile oder ein `asant`-Ziel verwenden, ist der Server standardmäßig als Server festgelegt und Sie müssen keine weiteren Änderungen vornehmen.

# Lifecycle-Verwaltung

In diesem Abschnitt werden die bekannten Probleme der Lifecycle-Verwaltung sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6193449 | Nachdem der Wert der `ejb-timer-service`-Eigenschaft minimum-delivery-interval auf 9000 festgelegt wurde, kann der Wert der `ejb-timer-service`-Eigenschaft `redelivery-interval-in-mills` nicht auf 7000 festgelegt werden. Der set-Befehl schlägt fehl und folgender Fehler tritt auf:
    [echo] Admin-Task wurde gesetzt
    [exec] [Attribute(id=redelivery-interval-internal-in-millis) :
    Redelivery-Interval (7,000)
    muss größer oder gleich Minimum-delivery-interval-
    in-millis (9,000) sein]
    [exec] CLI137 Befehlssatz fehlgeschlagen.
`minimum-delivery-interval` ist das minimale Zustellungsintervall zwischen den Zustellungen innerhalb einer Timer-Periode. `redelivery-interval-in-mills` ist die Zeit, die der Timer-Dienst wartet, bis er nach einem fehlgeschlagenen `ejbTimeout` eine Neuzustellung startet. Die Logik, die zwischen dem Neuzustellungsintervall und dem minimalen Zustellungsintervall besteht, ist nicht korrekt, sodass Sie weder über die Benutzeroberfläche noch über die Befehlszeilenschnittstelle die Werte so setzen können, dass der minimale Zustellungsintervall größer ist als der Neuzustellungsintervall. Der Wert der Eigenschaft `minimum-delivery-interval-in-millis` muss immer höher oder gleich dem Wert der Eigenschaft `redelivery-interval-in-millis`des `ejb-Timer-Dienstes` sein. Das Problem ist, dass in Application Server eine falsche Validierungsprüfung durchgeführt wird, um zu überprüfen, ob der Wert für `redelivery-interval-in-millis` höher ist als der Wert für `minimum-delivery-interval-in-millis`. Lösung Verwenden Sie für diese Eigenschaften folgende Standardwerte:
    minimum-delivery-interval(default)=7000
    redelivery-interval-in-millis(default)=5000
Die Verwendung anderer Werte verursacht einen Fehler.

# Protokollierung

In diesem Abschnitt werden die bekannten Protokollierungsprobleme sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6180095 | Debug-Anweisung für `access,failure` verursacht einen Absturz von Application Server beim Starten. Das Setzen der Option `java.security.debug` für JVM verursacht einen Deadlock in der Server-Startinstanz. Das Problem tritt beispielsweise auf, wenn Sie für `domain.xml` die Option wie folgt gesetzt haben:
    <jvm-options>-Djava.security.debug=access,failure</jvm-options>
Zu diesem Zeitpunkt steht keine Lösung zur Verfügung. Verwenden Sie diese Option nicht.

# Message Queue

In diesem Abschnitt werden die bekannten Message Queue-Probleme sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6173308, 6189645, 6198481, 6199510, 6208728 | Erneuter JMS-Verbindungsaufbau ist bei bestimmten Timing-abhängigen Bedingungen nicht erfolgreich. Fehler beim erneuten Verbindungsaufbau in Timing-abhängigen Szenarien können durch verschiedene Probleme verursacht werden. Lösung Es gibt folgende Problemlösungen: die betroffenen Broker neu starten. die betroffenen Application Server-Instanzen neu starten.
6198465 | Das asynchrone Meldungs-Listener-Verhalten änderte sich in `appclient` von 8.0 zu 8.1 Update 2. Wenn der einzige Live-Thread im `app-client`-Container der asynchrone Meldungs-Listener ist, bleibt die übrige `appclient`-Virtual-Machine als Dämon bestehen. Dieses Verhalten ist eine Regression für alte Anwendungen, die asynchrone Empfänge in ACC ausführen. Dieses Problem beeinträchtigt Anwendungsclients, die einen JMS Message-Listener setzen und den Haupt-Thread beenden. Lösung Beenden Sie den Haupt-Thread nicht. Warten Sie, bis der Meldungs-Listener den Haupt-Thread benachrichtigt hat, bevor Sie den Haupt-Thread beenden.

# Überwachung

In diesem Abschnitt werden die bekannten Überwachungsprobleme sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6174518 | Einige Überwachungsstatistiken des HTTP-Service beinhalten keine nützlichen Informationen und sollten daher ignoriert werden. Beim Anzeigen der Überwachungsstatistiken einiger Elemente des HTTP-Service stimmen einige der angezeigten Werte nicht mit den aktuellen Werten überein oder sind immer 0. Insbesondere enthalten die folgenden Statistiken des HTTP-Service keine Informationen bezüglich Application Server und sollten daher ignoriert werden: `http-service` `load1MinuteAverage` `load5MinuteAverage` `load15MinuteAverage` `rateBytesTransmitted` `rateBytesReceived` `pwc-thread-pool` (als Element) Lösung Diese Überwachungen werden in zukünftigen Versionen entfernt und durch aussagekräftigere Informationen ersetzt.
6191092 | MBean zur Überwachung eines nicht bereitgestellten EJB-Moduls wird nicht entfernt, obwohl alle Statistiken unter diesem Überwachungsnamen entfernt wurden. Beispiel:
    EJBModuleMonitorMap().size() = 1  eventhough ejb module is
    undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01
Dies gilt sowohl für EJB-Module als auch für EJB-Anwendungen. Die leere überwachende MBean ist sowohl im Programm (MBean API) als auch im Ergebnis des Befehls `asadmin list/get` weiterhin vorhanden. Diagnose
    asadmin list -m "server.applications" zeigt folgenden Output:
    server.applications.MEjbApp
    server.applications.__ejb_container_timer_app
    server.applications.adminapp
    server.applications.admingui
    server.applications.com_sun_web_ui
    server.applications._export_install_nov-11_domains_domain1_applications
    _j2ee-modules_sqe_ejb_s1_01
Prüfen Sie folgende Statistiken:
    bin/asadmin list -m "server.applications._export_install_nov-11_domains
    _domain1_applications_j2ee-modules_sqe_ejb_s1_01"
    server.applications._export_install_nov-11_domains_domain1_applications_
    j2ee-modules_sqe_ejb_s1_01.SQEMessage
    server.applications._export_install_nov-11_domains_domain1_applications_
    j2ee-modules_sqe_ejb_s1_01.TheGreeter
Nachdem die Bereitstellung aufgehoben wurde:
    _export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_
    ejb_s1_01
Wenn Sie einen list-Befehl ausführen, werden folgende Anwendungen nach wie vor angezeigt:
    asadmin list -m "server.applications"
    server.applications.MEjbApp
    server.applications.__ejb_container_timer_app
    server.applications._export_install_nov-11_domains_domain1_applications_
    j2ee-modules_sqe_ejb_s1_01
    server.applications.adminapp
    server.applications.admingui
    server.applications.com_sun_web_ui
Die folgenden Überwachungsstatistiken sind nicht enthalten:
    asadmin list -m "server.applications._export_install_nov-11_domains_
    domain1_applications_j2ee-modules_sqe_ejb_s1_01"
    Nothing to list at server.applications.-export-install-nov-11-domains-
    domain1-applications-j2ee-modules-sqe-ejb-s1-01.
Verwenden Sie das Platzhalterzeichen "`*`", um die gültigen Namen abzurufen, die mit einer Zeichenkette beginnen. Um beispielsweise alle überwachbaren Einheiten aufzulisten, die mit Server beginnen, verwenden Sie die Zeichenfolge list "`server.*`". Lösung Dies ist kein ernsthaftes Problem. Die Bereitstellung des Moduls kann sicher und problemlos aufgehoben werden. Die Mbean zur Root-Überwachung wurde nicht entfernt, sondern ist leer.

# PointBase

In diesem Abschnitt werden die bekannten PointBase-Probleme und ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6184797 | Bei der Festlegung von Isolationsstufen in einem Verbindungspool für eine Anwendung treten Ausnahmefehler in PointBase auf. Für einen JDBC-Verbindungspool, der auf eine PointBase-Datenbankinstallation zeigt, gilt Folgendes: Wenn das Poolattribut transaction-isolation-level auf einen anderen Wert als den Standardwert (`Connection.``TRANSACTION_READ_COMMITTED`) gesetzt wird, tritt ein Ausnahmefehler auf. Wenn jedoch dieser Parameter auf Nicht-Standardwerte für Pools gesetzt wird, die auf andere Datenbanken zeigen, tritt kein Ausnahmefehler auf. Lösung Vermeiden Sie die Verwendung des Attributs `transaction-isolation-level` für einen JDBC-Verbindungspool, der auf eine PointBase-Datenbankinstallation zeigen soll.
6204925 | PointBase gibt einen Ausnahmefehler aus, wenn ein Netzwerkserver und eingebettete Treiber zusammen verwendet werden. Die Paket-PointBase gibt manchmal einen Ausnahmefehler aus, wenn der Netzwerkserver-Treiber und der eingebettete Treiber gleichzeitig verwendet werden. Lösung Verwenden Sie entweder den eingebetteten Treiber oder den Netzwerktreiber. Verwenden Sie nicht beide Treiber.
6264969, 6275448 | Upgrade-Problem, wenn die standardmäßige PointBase-Datenbank überschrieben wird. Beim Upgrade auf Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2 überschreibt der Patch der Update-Version die standardmäßige Pointbase-Datenbank. Lösung Erstellen Sie alle vor dem Upgrade existierenden Schemata neu oder geben Sie diese erneut ein. Wenn Sie Anwendungen mit CMP-Beans über die Option "generate table" bereitgestellt haben, müssen Sie die Bereitstellung der Anwendung aufheben oder die Anwendung erneut bereitstellen, damit die Tabellen erneut generiert werden.

# Beispiele

In diesem Abschnitt werden die bekannten Probleme zum Beispielcode der Anwendungsserver 8.1-Software und ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
- 6195092 | Unter Windows reagiert setup-one-machine-cluster nicht mehr, funktioniert aber unter Solaris; für `mqfailover` muss `Strg+C` gedrückt werden, um den Prozess abzubrechen. Dieser muss anschließend erneut ausgeführt werden. In `install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html,` wenn Sie folgende Befehle ausführen: Konsole 1
      cd Installationsverzeichnis\samples\ee-samples asant start-mq-master-broker1
- Konsole 2
      cd Installationsverzeichnis\samples\ee-samples asant start-mq-cluster-broker1
- Konsole 3
      cd Installationsverzeichnis\samples\ee-samples asant start-mq-cluster-broker2
- Konsole 4
      cd Installationsverzeichnis\samples\ee-samples asadmin start-domain domain1
Wenn Sie für ein anderes EE-Beispiel bereits `asant setup-one-machine-cluster-without-ha` oder `asant setup-one-machine-cluster-with-ha` ausgeführt haben, führen Sie `asant configure-mq` aus. Führen Sie anderenfalls `asant setup-one-machine-cluster-and-configure-mq` aus. Die Meldung zeigt an, dass der Befehl erfolgreich ausgeführt wurde:
    start_nodeagent: [echo] Starten des Knoten-Agenten cluster1-nodeagent
    [exec] Befehl start-node-agent erfolgreich ausgeführt.
Das System bleibt jedoch hängen und reagiert nicht mehr. Lösung Zu diesem Zeitpunkt steht keine Lösung zur Verfügung. Dieses Problem beeinträchtigt auf ähnliche Weise alle Enterprise Edition-Beispiele, die dieses ant-Ziel unter Windows verwenden. Zur Problemlösung drücken Sie `Strg+C`, um den nicht mehr reagierenden Prozess zu beenden, und führen Sie ihn dann erneut aus.
6198003 | In der Dokumentation ist nicht ausdrücklich angegeben, dass Sie JMS-Ressource erstellen müssen, bevor die Beispielanwendung für das MQ-Failover im Anschluss an die `asadmin`-Bereitstellungsanweisungen ausgeführt wird. Folgender Fehler wird ausgegeben:
    /opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name
    MQFailoverTestClient -textauth -user j2ee -password j2ee
    Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl
    bindObjects
    SEVERE: NAM0006: JMS-Zielobjekt nicht gefunden: jms/durable/TopicA
    Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl
    bindObjects
    SEVERE: javax.naming.NameNotFoundException
    javax.naming.NameNotFoundException
In der Dokumentation wird nicht ausdrücklich erwähnt, dass bei einer manuellen Bereitstellung mit den Befehlen `asadmin deploy` JMS-Ressourcen manuell erstellt und die vorgegebenen ant-Ziele für das Bereitstellen derselben Software verwendet werden müssen. Lösung Verwenden Sie für das Skript `build.xml` das Ziel `asant`-Bereitstellung. Das Skript erstellt die für die Ausführung der Anwendung erforderlichen JMS-Ressourcen.
6198239 | Unter Linux wird bei der Zertifikaterstellung von Beispielen in webservices/security ein Laufzeitfehler angezeigt. Wenn Sie das Beispiel `install_dir/samples/webservices/security` sample (`basicSSl`) unter Linux bereitstellen, wird das Zertifikat nicht erstellt und ein Fehler ausgegeben, der etwa dem Folgenden entspricht:
    generate_certs: [echo] ***Export des Zertifikats von der NSS-Datenbank
    [exec] Ergebnis: 1 [echo] ***Erzeugen eines Java-Schlüsselspeichers anhand
    des generierten Zertifikats [exec] Keytool-Fehler: java.lang.Exception: Input kein
    X.509-Zertifikat [exec] Ergebnis: 1 [echo] ***Erzeugen eines Java-
    Vertrauensspeichers anhand des generierten Zertifikats [exec] Keytool-Fehler:
    java.lang. Ausnahmefehler: Input kein X.509-Zertifikat [exec] Ergebnis: 1
    .
    .
    .
    generate_certs: [echo] ***Export des Serverzertifikats von der NSS-Datenbank in
    eine PKCS12-Zertifikatdatei [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/
    libnss3.so: Version `NSS_3.9' nicht gefunden (von /opt/sun/appserver/lib/
    pk12util gefordert) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so:
    Version `NSS_3.6' nicht gefunden (von /opt/sun/appserver/lib/pk12util gefordert)
    [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: Version
    `NSS_3.7' nicht gefunden (von /opt/sun/appserver/lib/pk12util gefordert) [exec]
    Ergebnis: 1
- Das Problem besteht darin, dass sich NSS-Bibliotheken bei Linux-Installationen in anderen Pfaden befinden als bei Solaris-Installationen. Bei der Bereitstellung unter Linux müssen Sie sicherstellen, dass `LD_LIBRARY_PATH` auf die richtigen NSS-Bibliotheken verweist. Setzen Sie die Variable `LD_LIBRARY_PATH` entweder in Ihrer Umgebung oder im Shell-Wrapper-Skript `Installationsverzeichnis/bin/asant`. Lösung Gehen Sie folgendermaßen vor: Setzen Sie die Variable wie folgt: `LD_LIBRARY_PATH=/opt/sun/private/lib`. Fügen Sie dem Skript `install_dir /bin/asant` folgende Zeile hinzu:
      LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH

# Sicherheit

In diesem Abschnitt werden die bekannten Probleme und ihre Lösungen von Sicherheitsfunktionen in Anwendungsserver, Webanwendungen sowie Zertifikaten beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6183318 | Fehler beim Ausführen von `WebServiceSecurity`-Anwendungen bei Enterprise Edition mit J2SE 5.0. `WebServiceSecurity`-Anwendungen können aus folgendem Grund nicht mit J2SE 5.0 ausgeführt werden: J2SE 5.0 PKCS11 unterstützt den UNWRAP-Modus nicht. J2SE 5.0 PKCS11 unterstützt `RSA/ECB/OAEPWithSHA1AndMGF1Padding` nicht mit PKCS11 Das J2SE-Team hat "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms" für die Behebung dieses Fehlers bereitgestellt. Lösung Verwenden Sie J2SE 1.4.2 mit einem anderen JCE-Provider (und nicht mit dem enthaltenen Standard-Provider). Beachten Sie, dass bei dieser Konfiguration kein Software-Beschleuniger unterstützt wird.
6269102 | Die SSL-Beendigung funktioniert nicht; wenn Load Balancer (Hardware) für die SSL-Beendigung konfiguriert ist, ändert Anwendungsserver das Protokoll während der Umleitung von `https` zu `http`. Lösung Fügen Sie zwischen dem Hardware-Lastausgleich und Anwendungsserver einen Software-Lastausgleich hinzu.

# Aufrüsten

In diesem Abschnitt werden die bekannten Probleme beim Aufrüsten sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
6165528 | Die Domänen, die in custom-path erstellt werden und nicht dem Verzeichnis `install_dir /domains` entsprechen, werden während des Upgrades von Application Server Enterprise Edition 8 zu Application Server Enterprise Edition 8.1 nicht direkt aktualisiert. Wenn Sie das Programm zum Aufrüsten ausführen und dabei das `install_dir` als Quellverzeichnis für die Installation verwenden, werden beim Aufrüsten nur die Domänen aktualisiert, die sich im Verzeichnis `install_dir/domains` befinden. Für in anderen Pfaden erstellte Domänen wird kein Upgrade durchgeführt. Lösung Kopieren Sie alle Domänenverzeichnisse aus den jeweiligen Speicherorten in das Verzeichnis `Installationsverzeichnis/domains`, bevor Sie das Programm zum Aufrüsten ausführen.
2. 6207337 | In einigen Linux-Systemen kann der Installer beim Ausführen von "Upgrade in place" das Upgrade-Tool nicht starten, nachdem Sie auf die Schaltfläche "Start Upgrade Wizard" geklickt haben. Dieses Problem wurde bei verschiedenen Linux-Systemen beobachtet. Es tritt am häufigsten bei Java Desktop System 2 auf, wurde jedoch auch in Distributionen von Red Hat beobachtet. Wenn Sie auf der letzten Seite des Installationsprogramms auf die Schaltfläche "Start Upgrade Tool" klicken, wird das Upgrade-Tool nicht gestartet und der Upgrade-Vorgang nicht abgeschlossen. Das Upgrade-Tool reagiert nicht mehr und gibt keine Eingabeaufforderung aus. Lösung Dieses Problem tritt nicht auf, wenn das In-Place-Upgrade im Befehlszeilen-Installationsmodus ausgeführt wird. Wenn Sie das In-Place-Upgrade im Benutzeroberflächenmodus ausführen und dieses Problem auftritt, beenden Sie das Installationsprogramm, indem Sie in dem Terminal-Fenster, von dem aus das Installationsprogramm gestartet wurde, STRG+C drücken. Starten Sie das Upgrade-Tool vom Terminal-Fenster aus, indem Sie folgenden Befehl eingeben:
       Installationsverzeichnis/bin/asupgrade --source install_dir/domains --target
       install_dir --adminuser adminuser --adminpassword adminpassword
       --masterpassword changeit
3. Die Werte für Administrator und Administratorpasswort müssen mit den Werten übereinstimmen, die in der aufzurüstenden Installation verwendet werden. Wenn das Upgrade-Tool den Upgrade-Prozess beendet hat, können Sie auch den Browser starten und den folgenden URL eingeben, um die Infoseite anzuzeigen:
       file://Installationsverzeichnis/docs-ee/about.html
Wenn Sie auch noch die Installationsoption zum Registrieren des Produkts gewählt haben, folgen Sie dem Link der Registrierungsseite, der sich auf der Produktinfo-Seite befindet.
6296105 | Das selbst signierte Zertifikat wird während und nach einem Upgrade von 8.0 Platform Edition (PE) zu 8.1 Enterprise Edition (EE) UR2 nicht als vertrauenswürdig erkannt. Lösung Entfernen Sie die folgenden Einträge aus der Zieldatei `domain.xml` (nach dem Upgrade) und starten Sie den Server neu:
    <jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}
    /config/keystore.jks</jvm-options>-
    <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}
    /config/cacerts.jks</jvm-options>

# Webcontainer

In diesem Abschnitt werden die bekannten Probleme mit Webcontainern sowie ihre Lösungen beschrieben.

Bug-ID | Zusammenfassung
--- | ---
5004315 | Wird unter Windows eine Anwendung mit `--precompilejsp=true` bereitgestellt, können JAR-Dateien der Anwendung gesperrt werden, sodass das Aufheben der Bereitstellung oder eine neue Bereitstellung zu einem späteren Zeitpunkt nicht möglich ist. Wenn Sie beim Bereitstellen einer Anwendung unter Windows eine Vorkompilierung der JSPs anfordern, funktionieren spätere Versuche zum Aufheben der Bereitstellung dieser Anwendung oder zum erneuten Bereitstellen der Anwendung (oder einer anderen Anwendung mit derselben Modul-ID) nicht wie erwartet. Das Problem liegt darin begründet, dass durch die JSP-Vorkompilierung JAR-Dateien in Ihrer Anwendung geöffnet, jedoch nicht wieder geschlossen werden, und Windows verhindert, dass zur Aufhebung der Bereitstellung diese Dateien gelöscht oder zur erneuten Bereitstellung diese Dateien überschrieben werden. Beachten Sie, dass das Aufheben der Bereitstellung erfolgreich durchgeführt wird, bis die Anwendung aus Application Server logisch entfernt wird. Außerdem gibt das `asadmin`-Programm keine Fehlermeldung aus, obwohl das Anwendungsverzeichnis und die gesperrten JAR-Dateien auf dem Server weiterhin vorhanden sind. Die Protokolldatei des Servers enthält jedoch Fehlermeldungen, die Sie über den fehlgeschlagenen Löschvorgang der Dateien und des Verzeichnisses der Anwendung informieren. Die Versuche zum erneuten Bereitstellen der Anwendung nach der Aufhebung der Bereitstellung schlagen fehl, da der Server versucht, die vorhandenen Dateien und Verzeichnisse zu entfernen, was ebenfalls nicht möglich ist. Dieser Fehler tritt beispielsweise auf, wenn Sie versuchen, eine Anwendung mit der Modul-ID der ursprünglich bereitgestellten Anwendung bereitzustellen, da der Server die Modul-ID für die Auswahl eines Verzeichnisses für das Speichern der Dateien der Anwendung verwendet. Aus demselben Grund schlägt auch der Versuch fehl, die Anwendung erneut bereitzustellen, ohne dass die Bereitstellung zuvor aufgehoben wurde. Diagnose Wenn Sie die Anwendung erneut bereitstellen möchten oder die Anwendung bereitstellen möchten, nachdem Sie die Bereitstellung der Anwendung zuvor aufgehoben haben, gibt das asadmin-Programm eine Fehlermeldung aus, die etwa der folgenden Meldung entspricht:
    Beim Ausführen des Befehls ist ein Ausnahmefehler aufgetreten.
    Die Ausnahmemeldung lautet: CLI171 Bereitstellung des Befehls
    fehlgeschlagen: Bereitstellung der Anwendung in der Domäne
    fehlgeschlagen; Bereitstellung nicht möglich. Modulverzeichnis ist gesperrt
    und kann nicht gelöscht werden.
Lösung Wenn Sie bei der Bereitstellung einer Anwendung `--precompilejsps=false` (die Standardeinstellung) festlegen, tritt dieses Problem nicht auf. Beachten Sie, dass beim ersten Aufruf der Anwendung die JSP-Kompilierung ausgelöst wird, sodass die Antwortzeit für den ersten Aufruf länger ist als für folgende Aufrufe. Beachten Sie weiterhin, dass Sie im Falle einer Vorkompilierung den Server stoppen und erneut starten müssen, bevor Sie die Bereitstellung der Anwendung aufheben oder die Anwendung erneut bereitstellen. Durch den Prozess des Herunterfahrens werden die gesperrten JAR-Dateien wieder freigegeben, sodass die Aufhebung der Bereitstellung oder die erneute Bereitstellung nach dem Neustart erfolgreich ist.
6172006 | WAR kann nicht mit Servlet 2.4-basierter Datei `web.xml`, die ein leeres `<load-on-startup>`-Element enthält, bereitgestellt werden. Das optionale load-on-startup servlet-Element in der Datei `web.xml` gibt an, dass das zugehörige Servlet als Teil des Startvorgangs der die Deklaration ausführenden Webanwendung geladen und initialisiert werden muss. Für dieses Element kann optional eine ganze Zahl angegeben werden, mit der festgelegt wird, in welcher Reihenfolge das Servlet mit Bezug auf die anderen Servlets der Anwendung geladen und initialisiert werden soll. Wenn für `<load-on-startup>` kein Wert angegeben ist, wird keine bestimmte Reihenfolge berücksichtigt und es wird lediglich festgelegt, dass das Servlet beim Start der entsprechenden Webanwendungen geladen und initialisiert wird. Das Servlet 2.4-Schema für `web.xml` unterstützt keine leere `<load-on-startup>` mehr; dies bedeutet, dass bei Verwendung einer Servlet 2.4-basierten `web.xml` eine Ganzzahl angegeben werden muss. Wenn eine leere `<load-on-startup>` angegeben wurde, wie in `<load-on-startup/>`, schlägt die Validierung von `web.xml` basierend auf dem Servlet 2.4-Schema für `web.xml` fehl, wodurch die Bereitstellung der Webanwendung fehlschlägt. Rückwärtskompatibilität: Die Angabe eines leeren <load-on-startup>-Elements ist mit Servlet 2.3-basierten `web.xml`-Dateien nach wie vor möglich. Lösung Geben Sie `<load-on-startup>0</load-on-startup>` an, wenn Sie eine Servlet 2.4-basierte `web.xml`-Datei verwenden, um anzugeben, dass die Servlet-Lastenreihenfolge irrelevant ist.
6184122 | JSP-Seite kann auf Servern mit geringen Ressourcen nicht kompiliert werden Der Zugriff auf die JSP-Seite erfolgt, aber die eigentliche Kompilierung wird durchgeführt und das Serverprotokoll enthält die Fehlermeldung "Unable to execute command" mit folgenden Stapelverlaufsinformationen:
    at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
    exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
    launch(Execute.java:416)
    at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427)
    at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
    executeExternalCompile(DefaultCompilerAdapter.java:448)
    at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
    (JavacExternal.java:81)
    at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)
    at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
    at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)
- Lösung Setzen Sie den Schalter für die JSP-Kompilierung fork auf false. Wählen Sie eine der folgenden Vorgehensweisen: Auf globaler Basis setzen Sie den Parameter "fork init" von JspServlet in `${S1AS_HOME}/domains/domain1/config/default-web.xml` auf "false":
      <servlet> <servlet-name>jsp</servlet-name>
      <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
      .... <init-param>
      <param-name>fork</param-name> <param-value>false</param-value>
      </init-param> .... </servlet>
- Um den Wert für eine einzelne Webanwendung festzulegen, setzen Sie in `sun-web.xml` den JSP-Konfigurationsparameter "fork" auf "false":
      <sun-web-app> <jsp-config> <property name="fork" value="false" />
      </jsp-config> </sun-web-app>
Diese Einstellung verhindert, dass ant neue Prozesse für die javac -Kompilierung erzeugt.
6188932 | Application Server unterstützt nicht das Add-On `auth-passthrough` von Web Server 6.1. Sun Java System Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2 fügt Unterstützung für die Funktionalität hinzu, die durch das Plugin `auth-passthrough` bereitgestellt wird, welches in Sun Java System Anwendungsserver Enterprise Edition 7.1 enthalten ist. In Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2 ist jedoch die Plugin-Funktion `auth-passthrough` anders konfiguriert. Die Funktion des Plugins `auth-passthrough` in Anwendungsserver Enterprise Edition 7.1 hat sich in zweischichtigen Bereitstellungsszenarien als nützlich erwiesen, für die Folgendes gilt: Die Instanz von Application Server wird durch eine zweite Firewall hinter der firmeneigenen Firewall geschützt. Es sind keine direkten Client-Verbindungen mit der Instanz von Application Server zulässig. In derartigen Netzwerkarchitekturen stellen Clients eine Verbindung mit einem Front-End-Webserver her, der mit der Plugin-Funktion `service-passthrough` konfiguriert wurde, und leiten HTTP-Anforderungen zum Verarbeiten an die Proxy-Instanz von Application Server weiter. Die Instanz von Application Server kann lediglich Anforderungen vom Proxy-Webserver erhalten. Direkte Anforderungen von Client-Hosts sind nicht möglich. Folglich erhalten alle auf der Proxy-Instanz von Application Server bereitgestellten Anwendungen, die Client-Informationen, wie z. B. die IP-Adresse des Clients, abfragen, die IP des Proxy-Hosts, da dies der tatsächliche Ursprungs-Host der weitergeleiteten Anforderung ist. In Anwendungsserver Enterprise Edition 7.1 kann die Funktion des Plugins `auth-passthrough` auf der Proxy-Instanz von Application Server konfiguriert werden, um die Informationen des Remote-Clients allen auf ihm bereitgestellten Anwendungen direkt zur Verfügung zu stellen, als ob die Proxy-Instanz von Application Server die Anfrage auf direkte Weise und nicht über einen intermediären Webserver erhalten hätte, auf dem das Plugin `service-passthrough` ausgeführt wird. In Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2, kann die `auth-passthrough` -Funktion aktiviert werden, indem die Eigenschaft `authPassthroughEnabled` des `<http-service>`-Elements in der DAtei `domain.xml` wie folgt auf TRUE festgelegt wird:
    <property name="authPassthroughEnabled" value="true"/>
| Dieselben Sicherheitserwägungen für die Funktion des Plugins `auth-passthrough` in Anwendungsserver Enterprise Edition 7.1 gelten auch für die Eigenschaft `authPassthroughEnabled` in Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2. Da `authPassthroughEnabled` ermöglicht, Informationen zu umgehen, die für Authentifizierungszwecke verwendet werden können (wie z. B. die IP-Adresse, von der die Anforderung ausging, oder das SSL-Clientzertifikat), ist es erforderlich, dass nur vertrauenswürdigen Clients oder Servern das Recht gewährt wird, eine Verbindung mit einer Instanz von Anwendungsserver Enterprise Edition 8.1 2005Q2 Update 2 herzustellen, wenn `authPassthroughEnabled` auf TRUE festgelegt ist. Als Vorsichtsmaßnahme wird empfohlen, dass nur Server hinter der firmeneigenen Firewall mit dem auf TRUE gesetzten Befehl `authPassthroughEnabled` konfiguriert werden. Ein Server, der über das Internet aufgerufen werden kann, darf niemals mit dem auf TRUE gesetzten Befehl `authPassthroughEnabled` konfiguriert werden. Beachten Sie, dass in dem Fall, wenn ein Proxy-Webserver mit dem Plug-In `service-passthrough` konfiguriert wurde und Anforderungen an eine Instanz von Application Server 8.1 Update 2 mit der auf TRUE gesetzten Eigenschaft `authPassthroughEnabled` weiterleitet, die SSL-Clientauthentifizierung auf dem Webserver-Proxy aktiviert und auf der Proxy-Instanz von Application Server 8.1 Update 2 deaktiviert sein kann. In diesem Fall behandelt die Proxy-Instanz von Application Server 8.1, Update 2 die Anforderung immer noch so, als wäre diese per SSL authentifiziert worden und stellt das SSL-Zertifikat des Clients allen bereitgestellten Anwendungen zur Verfügung, wenn diese es anfordern.

- Previous: Kapitel 2 Info über Anwendungsserver Enterprise Edition 8.1 2005Q2

- © 2010, Oracle Corporation and/or its affiliates