In diesem Kapitel sind bekannte Probleme und die entsprechenden Umgehungen für die Sun Java System Application Server 9.1-Software beschrieben. Wenn für ein Problem keine spezielle Plattform angegeben ist, betrifft es alle Plattformen. Diese Informationen sind in die folgenden Abschnitte unterteilt:
In diesem Abschnitt werden bekannte Verwaltungsprobleme sowie ihre Lösungen beschrieben.
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.
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.
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.
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.
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.
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 zum 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 Sun Java System Application Server 9.1 Administration Guide .
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.
Ändern Sie die Berechtigungen in den Skripts:
chmod 755 appserv/domains/domain-name/bin/* |
Beim Einrichten der Lastenausgleichskonfiguration mit einer Anwendung, die über ein EJB-Modul verfügt und einen Webservice-URL exportiert, befindet sich das Kontext-Stammverzeichnis (root) für den Webservice nicht in der resultierenden Datei loadbalancer.xml.
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.
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.
Die Datei .asadmintruststore wird in der Application Server-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.
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.
Der standardmäßige MQ-Integrationsmodus für eine Application Server-Cluster-Instanz lautet LOCAL. Wenn Application Server in einem Verzeichnis (PATH) installiert wird, das lang (also "not short") ist, stürzt imqbrokerscv.exe beim Starten der Cluster-Instanz ab. Das Problem wird durch die Speicherzuweisung in imqbrokersvc verursacht.
Der JMS-Diensttyp für die Cluster-Instanz muss vom Standardwert LOCAL in REMOTE geändert werden. In dieser Konfiguration zeigen alle Instanzen auf den DAS-Broker. Befolgen Sie die unten stehenden Anweisungen zum Konfigurieren eines Clusters im REMOTE-Modus.
Bei Auswahl des REMOTE-Modus verwenden alle Instanzen einen Broker (DAS), sodass beim Start des Application Server-Clusters kein Broker-Cluster erstellt wird. Weitere Informationen finden Sie in Abschnitt 4.1, Unterabschnitt iii, "Auto-clustering" des einseitigen Dokuments unter http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt. Die oben stehende Funktionalität ist nicht verfügbar!
Ändern Sie den Port und die Passwortdatei gemäß Ihrer Umgebung. Beachten Sie, dass im unten stehenden Beispiel der Clustername racluster, der DAS-Admin-Port 5858 und der DAS JMS-Port 7676 lautet.
Ändern Sie die Clusterkonfiguration, und ändern Sie den JMS-Typ in REMOTE .
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE |
Erstellen Sie einen JMS-Host in Übereinstimmung mit dem DAS JMS-Host.
$AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
Legen Sie für den JMS-Host den DAS JMS-Host fest, der im vorherigen Schritt erstellt wurde.
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost |
Wechseln Sie zu "Konfigurationen"->Clustername-config->"Java Message Service"->"JMS-Hosts".
Klicken Sie auf Neu, um einen neuen JMS-Host zu erstellen; wählen Sie für diesen Host den Namen dashost.
Geben Sie die Konfigurationseinstellungen in Übereinstimmung mit dem JMS-Dienst für den DAS ein; die Standardwerte lauten wie folgt:
Hostname: localhost
Port: 7676
Admin-Benutzer: admin
Passwort: admin
Ändern Sie diese Einstellungen nach Bedarf für Ihren DAS JMS-Dienst.
Wechseln Sie erneut auf die Registerkarte "Java Message Service", und ändern Sie den JMS-Diensttyp in REMOTE (der Standardwert lautet LOCAL).
Wählen Sie dashost aus der Dropdown-Liste default-jms-host aus.
Speichern Sie die Änderungen, und starten Sie den Knotenagenten oder Cluster.
Beim Versuch, ein Diagramm von der Seite zur Überwachung der Protokollstatistik über einen nicht unterstützten Browser anzuzeigen, wird möglicherweise die folgende Fehlermeldung angezeigt:
Fehler beim Laden von jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Skript: http://easqelx5.red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Meldung: area.initialize ist keine Funktion |
Verwenden Sie einen unterstützten Browser. Eine Liste der in Application Server 9.1 unterstützten Browser finden Sie unter Browser.
Der standardmäßige Admin-Port wurde in jeder der drei vergangenen Versionen von Application Server geändert. Für die Versionen 7.x, 8. x und 9.x lautet der standardmäßige Admin-Port wie folgt:
AS 7.x: 4848
AS 8.x: 4849
AS 9.x: 4848
Dies ist kein Fehler, sollte jedoch beachtet werden. Der standardmäßige Admin-Port ist lediglich eine Empfehlung. Es wird davon ausgegangen, dass in zukünftigen Versionen von Application Server der Standardport 4848 beibehalten wird.
In diesem Abschnitt werden bekannte Probleme des Apache Webservers und des Lastenausgleich-Plugins sowie zugehörige Lösungen erläutert.
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.
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.
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.
In diesem Abschnitt werden bekannte Probleme des Anwendungsclients sowie ihre Lösungen beschrieben.
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.
Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.
Der Anwendungsclient versucht stets, eine Verbindung mit localhost:3700 herzustellen. Das Problem ist, dass mehrere Systemeigenschaften gelesen werden müssen, bevor der Clientcode aufgerufen wird.
Setzen Sie die folgenden Werte als Systemeigenschaften (-D in JAVA_CMD). Setzen Sie diese Werte nicht in Ihrem appclient-Code:
org.omg.CORBA.ORBInitialHost = Serverinstanzhost org.omg.CORBA.ORBInitialPort = Serverinstanzport |
Bei Ausführung auf Linux mit 64–Bit wird beim Starten der Domäne die folgende Ausnahme ausgelöst. Das Problem wird durch eine nicht vorhandene Datei sunpkcs11.jar im Verzeichnis jdk1.5.0_11/jre/lib/ext/ ausgelöst.
Dies ist ein bekannter JDK-Fehler bei 64–Bit-Versionen von Linux. Dieses Problem wird in JDK 1.5.0_13 behoben.
Wenn ein SocketChannel für mehr als eine Auswahl registriert ist, wird für socketChannel.keyFor(lastRegisteredSelector) anstelle von SelectionKey Null zurückgegeben.
Dieses Problem hängt mit dem JDK-Problem 6562829 zusammen und wird voraussichtlich in 6.0 U3 behoben. In Application Server 9.1 wurde eine Umgehung implementiert, sodass das Wrapping für die Auswahl aufgehoben wird, bevor die API keyFor aufgerufen wird. Dadurch kann keyFor erfolgreich durchgeführt werden, bis das JDK-Problem behoben wurde.
In diesem Abschnitt werden bekannte Probleme der im Lieferumfang enthaltenen Sun JDBC-Treiber sowie ihre Lösungen beschrieben.
Wenn eine Anwendung mehr als 3000 PreparedStatement -Objekte in einer Transaktion generiert, kann für DB2 der folgende Fehler auftreten:
[sunm][DB2 JDBC Driver] No more available statements. Erstellen Sie Ihr Paket mit einem höheren dynamicSections-Wert neu.
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 Sun Java System Application Server 9.1 Administration Guide.
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.
Erhöhen Sie den Wert des Konfigurationsparameters APPLHEAPSZ des DB2-Servers. Ein geeigneter Wert ist 4096.
Isolationsebene TRANSACTION_SERIALIZABLE Wenn eine Anwendung die Isolationsebene TRANSACTION_SERIALIZABLE und einen der oben genannten Parameter verwendet, kann die Anwendung beim Verbindungsaufbau abstürzen.
Um die Isolationsebene für eine Verbindung wie gewünscht setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Anweisungen finden Sie im Sun Java System Application Server 9.1 Administration Guide .
Die im Paket enthaltene Java DB-Datenbank wird nach dem Neustarten eines Hostsystems oder einer Solaris-Zone bzw. nach dem Starten von Application Server nicht automatisch neu gestartet. Dies ist kein Fehler, sondern das erwartete Verhalten für Anwendungen, die im Paket enthalten sind, bzw. für Drittanbieteranwendungen. Das Problem ist, dass die Java DB vor der Application Server-Instanz gestartet werden muss.
Stellen Sie nach dem Neustart des Hostcomputers oder einer Solaris-Zone sicher, dass Sie die Java DB vor Application Server starten. Beispiel:
/opt/SUNWappserver/appserver/bin/asadmin start-database |
Weitere Informationen zu den Optionen des asadmin-Befehls finden Sie unter "Application Server Administration Tools" in "Sun Java System Application Server 9.1 Quick Start Guide".
In diesem Abschnitt werden die bekannten Probleme mit der Dokumentation sowie ihre Lösungen beschrieben.
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.
Der folgende Ausnahmefehler tritt im Thread "main" auf: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.
Die Verwendung der Paket-ANT für Funktionen außerhalb von Application Server wird nicht empfohlen.
In diesem Abschnitt werden bekannte Probleme mit der Hochverfügbarkeits-Datenbank (HADB) und zugehörige Lösungen erläutert.
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).
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.
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.
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.
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.
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. |
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.
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() ).
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.
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. |
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.
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."
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.
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.
Verwenden Sie eine 32-Bit-Version von Red Hat Enterprise Linux 3.0.
Großbuchstaben in Passwörtern werden in Kleinbuchstaben umgewandelt, wenn das Passwort in hadb gespeichert wird.
Verwenden Sie keine Passwörter, die Großbuchstaben enthalten.
Beim Downgrading auf eine vorherige HADB-Version kann der Management-Agent mit verschiedenen Fehlercodes fehlschlagen.
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.
Hinsichtlich der Installation/Deinstallation der HADB c-Paketversion (Solaris: SUNWhadbc, Linux: sun-hadb-c) <m.n.u-p> wird symlink /opt/SUNWhadb/<m> nicht mehr verändert, sobald dieser Symlink vorhanden ist. Daher ist es möglich, dass eine verwaiste symlink vorhanden ist.
Löschen Sie symlink vor der Installation oder nach der Deinstallation; es sei denn, die Datei wird verwendet.
Unter Solaris 10 wird beim Anhalten eines Management-Agents unter Verwendung des Skripts ma-initd in einer globalen Zone auch der Management-Agent in der lokalen Zone angehalten.
Installieren Sie den Management-Agent nicht sowohl in der globalen als auch der lokalen Zone.
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.
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.
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.
Die Installation mit Java Enterprise System (als Root) gibt von Root verschiedenen Benutzern keine Benutzerrechte zum Verwalten von HADB.
Melden Sie sich immer als Root an, um HADB zu verwalten.
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.
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.
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.
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.
Cookies mit einem Pfad "/" wirken sich auf die Cookies einer hochverfügbaren Webanwendung aus, die in einem anderen Kontext-Root als "/" bereitgestellt werden, der die In-Memory-Replikation als Persistenztyp verwendet. Dadurch wird es für die hochverfügbare Webanwendung unmöglich, einen HTTP-Sitzungsstatus beizubehalten. Ein häufiges Szenario, in dem dies auftreten kann, ist, wenn derselbe Browser für den Zugriff auf die Admin-GUI (unter "/" bereitgestellt) und die hochverfügbare Webanwendung verwendet wird.
Greifen Sie über einen anderen Browser auf die Webanwendung zu, die unter "/" bereitgestellt wird.
SASL32.DLL und ZLIB.DLL sind erforderliche Dateien, damit der Lastenausgleich mit Windows IIS 6 funktioniert. Diese Dateien sind gegenwärtig unter <Anwendungsserver-Installationsverzeichnis>/lib nicht vorhanden.
Kopieren Sie die beiden DLL-Dateien manuell in das Verzeichnis <Anwendungsserver-Installationsverzeichnis>/lib. Diese Dateien können unter folgender Adresse heruntergeladen werden:
http://download.java.net/javaee5/external/<Betriebssystem>/aslb/jars/aslb-9.1-MS4-b5.jar |
Dabei steht <Betriebssystem> für die gewünschte Plattform. Sie können einen der folgenden Werte wählen:
SunOS
SunOS_X86
Linux
WINNT
Bei der Installation oder Deinstallation von Application Server mit Hochverfügbarkeitspaketen in einer globalen Zone treten zwei Probleme auf:
HA-Pakete werden in sämtlichen Zonen installiert; dies ist möglicherweise nicht gewünscht.
Bei der Deinstallation werden HA-, MQ- und JDK-Pakete aus allen Zonen entfernt; dies ist möglicherweise nicht gewünscht.
Dieses Problem tritt nicht auf, wenn die Installation oder Deinstallation über eine lokale Root-Zone durchgeführt wird.
Führen Sie Installationen und Deinstallationen nicht über eine globale, sondern über eine lokale Zone durch.
Hochverfügbare Webanwendungen, die unter "/" bereitgestellt wurden, können keine HTTP-Sitzungen beibehalten, wenn als Persistenztyp die In-Memory-Replikation verwendet wird.
Stellen Sie hochverfügbare Webanwendungen, welche die In-Memory-Replikation als Persistenztyp verwenden, über einen anderen Kontext-Root als "/" bereit. Wenn Sie eine solche Webanwendung unter "/" bereitstellen möchten, können Sie sie als das Standardwebmodul des virtuellen Servers festlegen, für welchen die Webanwendung bereitgestellt wurde.
Während der Installation der Application Server-Lastenausgleichskomponente für Apache unter Solaris, aktualisiert das Installationsprogramm LD_LIBRARY_PATH im Skript apachectl . Dabei schreibt das Installationsprogramm den Pfad /usr/lib/mps jedoch nicht richtig. Unter Solaris kann die Apache-Sicherheitsinstanz ohne diesen Pfad in LD_LIBRARY_PATH nicht gestartet werden.
Dieses Problem tritt nur auf Solaris-Plattformen auf. Um dieses Problem zu vermeiden, fügen Sie /opt/SUNWappserver/appserver/lib/lbplugin/lib zu LD_LIBRARY_PATH hinzu.
Die Schaltfläche Lastenausgleich aktivieren ist auf der allgemeinen Seite für Cluster/Instanzen immer aktiviert, unabhängig davon, was in domain.xml gespeichert wurde.
Für Cluster-Instanzen wählen Sie die Registerkarte Instanzen, und wählen Sie im Tabellen-Pulldown-Feld die Aktion Stilllegen.
Für eigenständige Instanzen stellen Sie sicher, dass die Instanz ausgeführt wird, und klicken dann im Bildschirm "Allgemein" für die Instanz auf die Schaltfläche Stilllegen.
(Nur Solaris) Nach der Installation von Application Server 9.1 unter SPARC Solaris 10 mit HADB wird möglicherweise der folgende Fehler angezeigt, wenn Sie Application Server starten und anschließend versuchen, JES 5 UR1 mit Registry Server zu installieren:
Abhängigkeitsfehler: Installation kann nicht fortgesetzt werden, da die auf diesem Host ermittelte Version von HA Session Store 4.4.3 unvollständig ist und eine kompatible Version für den Service Registry-Bereitstellungs-Support erforderlich ist. |
Registry Server kann nicht von JES 5 UR1 mit Application Server 9.1 IFR auf Solaris-Computern installiert werden. Die Registry Server-Pakete müssen manuell über den Befehl pkgadd aus dem folgenden JES5 UR1-Distributionsverzeichnis installiert werden:
<Pfad>/<Betriebssystem>/Products/registry-svr/Packages |
(Nur Internet Explorer 6) Beim Versuch, die Lastenausgleichs-Konfigurationsdatei (loadbalancer.xml) aus Internet Explorer 6 zu exportieren, zeigt der Browser in einer Fehlermeldung an, dass die DTD-Datei sun-loadbalancer_1_2.dtd nicht ermittelt werden kann.
Verwenden Sie zum Speichern der Datei die folgende Umgehung:
Klicken Sie im Internet Explorer auf der Seite für den Lastenausgleich auf Export.
Die Meldung "XML-Seite kann nicht angezeigt werden" wird angezeigt.
Klicken Sie auf den Fehlerrahmen, und wählen Sie in Internet Explorer Datei->Speichern unter.
Speichern Sie die Datei loadbalancer.xml in einem Verzeichnis Ihrer Wahl.
In diesem Abschnitt werden die bekannten Installationsprobleme sowie ihre Lösungen beschrieben.
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.
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 den folgenden 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.
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.
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 |
Bei der Installation des im Paket enthaltenen SDK unter Windows Vista wird möglicherweise der Fehler "Nicht unterstützte Installationsplattform ermittelt." angezeigt. Die Installation kann jedoch ohne Probleme durchgeführt werden.
Dies ist kein wirkliches Problem. Application Server wird unter Windows Vista ausgeführt, und diese falsche Meldung wird in zukünftigen Produktversionen entfernt.
Wenn die Application Server-Datei productregistry Konfigurationen für gemeinsame Komponenten enthält, wird bei der Deinstallation von Application Server die Datei productregistry nicht ordnungsgemäß aktualisiert, und Sie können den Hintergrundmodus für eine anschließende Installation nur dann verwenden, wenn die Datei productregistry umbenannt oder entfernt wird. Das unveränderte Beibehalten der Einträge für gemeinsame Komponenten in der Datei productregistry verursacht zwar keine Fehler, führt jedoch bei einer anschließenden Installation im Hintergrundmodus zu Konflikten.
Nachdem Sie die erfolgreiche Deinstallation anhand der Protokolldateien überprüft haben, entfernen Sie die Datei productregistry, bevor Sie eine anschließende Installation durchführen. Zur Verifizierung, ob eine vorherige Deinstallation erfolgreich durchgeführt wurde, überprüfen Sie das <Installationsverzeichnis> nach einer Datei appserv_uninstall.class. Diese Datei ist nicht vorhanden, wenn die Deinstallation erfolgreich durchgeführt wurde.
Löschen Sie die Datei productregistry nicht, wenn die Deinstallation nicht erfolgreich war.
Die Datei productregistry befindet sich unter Solaris im Ordner /var/sadm/install und unter Linux im Ordner /var/tmp.
Die Installation von Application Server in einer lokalen Sparse-Zone schlägt fehl, wenn Message Queue (MQ) nicht zuerst installiert wurde. Das Installationsprogramm versucht, MQ zu installieren, und anschließend schlägt die gesamte Installation fehl.
MQ muss vor der Installation von Application Server in einer lokalen Sparse-Zone manuell in der globalen Zone installiert werden. Für dieses Problem gibt es zwei Umgehungen:
Installieren Sie zuerst MQ 4.1 manuell über dasselbe Medium in der globalen Zone, auf dem sich auch die Application Server 9.1 IFR-Installation befindet, um die aktuellsten MQ-Pakete bereitzustellen.
Verwenden Sie das geeignete Installationsprogramm für Ihre Plattform:
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip |
Dekomprimieren Sie die Dateien, und führen Sie das Installationsprogramm aus.
Das Installationsprogramm befindet sich im Verzeichnis mq4_1-installer.
Installieren Sie eine Komponente der IFR-Installation in der globalen Zone. Diese Aktion überprüft die Version von MQ in der GZ und führt gegebenenfalls ein Upgrade auf die mit Application Server 9.1 IFR kombinierte Version durch. Selbst bei Auswahl und Installation der Komponente der Beispielanwendung wird MQ auf die IFR-Version aktualisiert.
Führen Sie die Application Server-Installation in der globalen Zone durch, wählen Sie jedoch lediglich die Beispielkomponenten.
Bei der Installation der Beispielkomponente werden auch MQ und die gemeinsamen Application Server-Komponenten in allen Zonen installiert.
Führen Sie die Application Server-Installation erneut durch, diesmal jedoch in der lokalen Sparse-Zone.
Die Installation sollte ohne Probleme abgeschlossen werden.
Wenn Sie das Application Server 9.1 IFR-Intallationsprogramm mit der Option –console (Befehlszeilenmodus) ausführen, wird die folgende Aufforderung angezeigt:
Möchten Sie eine Aktualisierung von einer früheren Application Server-Version durchführen? |
Leider unterstützt das IFR-Installationsprogramm solche Aktualisierungen nicht, sodass diese Meldung falsch ist. Wenn Sie die Frage mit "Ja" beantworten, wird der Installationsprozess normal fortgesetzt, es wird jedoch nicht angezeigt, dass eine vollständige Installation (anstelle einer Aktualisierung) durchgeführt wurde.
Verwenden Sie das Upgrade-Tool, wenn Sie Ihre Application Server-Installation aktualisieren möchten.
Führen Sie die folgenden Aufgaben aus, um das Java EE 5-Lernprogramm für Sun Java System Application Server 9.1 auszuführen:
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.
Der standardmäßige Admin-Port in Application Server 9.1 ist erneut 4848 . Weitere Informationen finden Sie unter Standardports ändern sich in jeder Hauptversion von AS (6566481).
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.
In Kapitel 32, Java EE Examples Using the JMS API in The Java EE 5 Tutorial, An Application Example That Consumes Messages from a Remote Server in The Java EE 5 Tutorial " funktioniert dieses Beispiel nicht mehr. Die MDB empfängt die Nachricht nicht. Die beiden anderen Beispiele, die Nachrichten zwischen zwei Systemen senden, funktionieren weiterhin (Running JMS Client Programs on Multiple Systems in The Java EE 5 Tutorial und An Application Example That Deploys a Message-Driven Bean on Two Servers in The Java EE 5 Tutorial .
Dieses Problem wird in einem späteren Application Server-Build behoben.
Wenn die java.util.Arrays.asList()-API zum Konvertieren eines Object[]-Wertes in einen Collection-Wert verwendet wird, gibt das JDK eine Implementierung von java.util.ArrayList zurück, für die kein Klon erstellt werden kann. Dies führt zu folgender Ausnahme:
Der Methodenaufruf der Methode [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] für das Objekt [[pkg.A id = xxx]] der Klasse [class java.util.Arrays$ArrayList] hat eine Ausnahme ausgelöst. Interne Ausnahme: java.lang.reflect.InvocationTargetException Target Aufruf Ausnahme: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList |
Dieses Problem ist unter https://glassfish.dev.java.net/issues/show_bug.cgi?id=556 beschrieben.
Erstellen Sie eine weitere Sammlung unter Verwendung des Konstruktors; Beispiel:
myCollection = new ArrayList(java.util.Arrays.asList(a)) |
In diesem Abschnitt werden die bekannten Probleme der Lifecycle-Verwaltung sowie ihre Lösungen beschrieben.
Nachdem Sie die ejb-timer-service-Eigenschaft minimum-delivery-interval auf 9000 gesetzt haben, führt der Versuch, die ejb-timer-service-Eigenschaft redelivery-interval-in-mills auf 7000 zu setzen, zum Fehlschlagen des set-Befehls mit dem folgenden Fehler:
[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-millisdes 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.
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.
Beim Versuch, die physischen JMS-Ziele unter Verwendung von default-config anzuzeigen, wird eine Fehlermeldung angezeigt.
Dies ist das erwartete Verhalten. In Application Server 9.1, ist default-config eine Vorlage mit Konfigurationsinformationen, sodass JMS-Operationen (z. B. list und create) für default-config nicht ausgeführt werden können. Diese JMS-Operationen können jedoch für die Konfigurationen Ihrer Cluster- oder eigenständigen Instanzen ausgeführt werden.
(Nur Windows 2003) Die Verwendung von umfangreichen Zugriffsfunktionen auf Systemen unter Windows 2003 führt zu Speicherlecks. Das Problem tritt auf, da der nicht ausgelagerte Win32-Speicherpool kontinuierlich erweitert wird und dies letztendlich zum Fehlschlagen des gesamten TCP/IP-Stacks führt. Nach dem Fehlschlagen weist der TCP/IP-Stack einen nicht wiederherstellbaren Status auf. Die einzige Möglichkeit, den Stack wiederherzustellen, ist der Neustart des Windows 2003-Systems.
Dies ist ein Microsoft-Problem (Fallnummer: SRX070906600011), für das ein Hotfix verfügbar ist. Weitere Informationen erhalten Sie vom Microsoft-Support.
Neben dem oben genannten Hotfix gibt es zwei Umgehungen für dieses Problem.
Verwenden Sie den Grizzly-Sperrmodus, indem Sie das domain.xml http-listener-Attribut blocking-enabled="true" konfigurieren oder die folgende http-listener-Eigenschaft hinzufügen:
<property name="blocking" value="true"/> |
Verwenden Sie Windows Vista oder Windows XP.
In diesem Abschnitt werden die bekannten Protokollierungsprobleme sowie ihre Lösungen beschrieben.
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.
In diesem Abschnitt werden die bekannten Message Queue-Probleme sowie ihre Lösungen beschrieben.
Fehler beim erneuten Verbindungsaufbau in Timing-abhängigen Szenarien können durch verschiedene Probleme verursacht werden.
Es gibt folgende Problemlösungen:
die betroffenen Broker neu starten.
die betroffenen Application Server-Instanzen neu starten.
Nach dem Erstellen einer Domäne mit einem Cluster-Profil auf einem Linux-System kann ein java.lang.OutOfMemoryError: Java heap space-Fehler auftreten, und die Serverinstanz wird möglicherweise nicht gestartet, da der Start des MQ-Brokers fehlschlägt. Das System kann nach dieser Bedingung nicht fortgesetzt werden. Das Problem ist eine nicht ordnungsgemäß konfigurierte Datei /etc/hosts; genau gesagt, der Serverhostname zeigt auf die Loopback-Adresse 127.0.0.1.
Ein MQ-Broker-Cluster kann nicht gestartet werden, wenn das Netzwerkgerät auf die Loopback-Adresse zeigt. Dies ist kein Fehler. Um dieses Problem zu lösen, stellen Sie sicher, dass die /etc/hosts-Datei für den Application Server-Host nicht auf 127.0.0.1 zeigt.
In diesem Abschnitt werden die bekannten Überwachungsprobleme sowie ihre Lösungen beschrieben.
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)
Diese Überwachungen werden in zukünftigen Versionen entfernt und durch aussagekräftigere Informationen ersetzt.
Wenn die JNDI-Suche über die Admin-GUI geöffnet wird, werden eine Vielzahl von Ausnahmen ausgegeben.
Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.
In diesem Abschnitt werden die bekannten Probleme zum Beispielcode der Application Server 9.1-Software und ihre Lösungen beschrieben.
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.
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.
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.
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 |
Nach dem Upgrade auf Application Server 9.1 verwenden die Beispiele und die JES5-Portalbeispiele unter Windows den Derby-Port 1527. Genau gesagt, Application Server 9.1 startet JavaDB automatisch an Port 0.0.0.0:1527 mit APP:APP, die JES5-Portal-JavaDB versucht jedoch, eine Bindung an hostnameIP:1527 mit portal:portal herzustellen.
Dieses Problem ist bereits für JES 5 aufgetreten (Fehler 6472173). Die Umgehung für Fehler 6472173 ist im Sun Java Enterprise System 5 Installation Guide for Microsoft Windows dokumentiert.
Starten Sie die Derby-Datenbank über den folgenden Befehl:
<JES-Installationsverzeichnis>\appserver\bin\asadmin start-database --dbhome<JES-Installationsverzeichnis>\portal\data\derby |
In diesem Abschnitt werden die bekannten Probleme und ihre Lösungen von Sicherheitsfunktionen in Application Server, Webanwendungen sowie Zertifikaten beschrieben.
Die SSL-Beendigung funktioniert nicht; wenn Load Balancer (Hardware) für die SSL-Beendigung konfiguriert ist, ändert Application Server das Protokoll während der Umleitung von https zu http.
Fügen Sie zwischen dem Hardware-Lastausgleich und Application Server einen Software-Lastausgleich hinzu.
Aufgrund eines JVM-Fehlers tritt bei einigen JDK-Versionen ein Leckproblem auf, wenn security-enabled für ein HTTP-Zielgerät auf true gesetzt ist. Im Folgenden sind die Schritte zum Reproduzieren dieses Fehlers aufgelistet:
Setzen Sie security-enabled für das HTTP-Zielgerät auf true:
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id=" http-listener-1" port="8080" security-enabled="true" server-name="" xpowered-by="true"> |
Kommentieren Sie das Anhalten der Domäne am Ende von Quicklook-Tests heraus.
Führen Sie Quicklook-Tests aus.
Überprüfen Sie die Socket-Verwendung:
netstat -an | grep 8080 |
Die folgenden Elemente werden als verwendet angezeigt:
*.8080 *.* 0 0 49152 0 LISTEN *.8080 *.* 0 0 49152 0 BOUND |
Dieses Problem ist auf der Glassfish-Site unter https://glassfish.dev.java.net/issues/show_bug.cgi?id=849 beschrieben.
Führen Sie ein Upgrade auf die aktuellste JDK-Version durch.
In diesem Abschnitt werden die bekannten Probleme beim Aufrüsten sowie ihre Lösungen beschrieben.
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.
Kopieren Sie alle Domänenverzeichnisse aus den jeweiligen Speicherorten in das Verzeichnis Installationsverzeichnis/domains, bevor Sie das Programm zum Aufrüsten ausführen.
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.
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 |
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.
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>
Das Upgrade-Tool überschreibt vorhandene index.html-Dateien für alle Serverinstanzen.
Sichern Sie Ihre vorhandenen index.html-Dateien vor dem Ausführen des Upgrade-Tools, und stellen Sie diese Dateien später wiederher.
Bei der Aktualisierung von Application Server 8.0PE auf 9.1 wird in einem Fehler angezeigt, dass der Server nicht über einen System-Konnektor null und ungültige Benutzerinformationen in sbs-manual verfügt. Selbst nach dem Ändern der hartcodierten Werte wird diese Fehlermeldung angezeigt. Dieses Problem tritt auf, da die Datei domain.xml aus Version 8.0 in Version 9.1 geändert wurde.
Dieser Fehler tritt nur bei der Aktualisierung von 8.0 PE auf 9.1 auf. Als Umgehung führen Sie ein Upgrade auf 8.1, 8.2 oder 9.0 und erst anschließend auf 9.1 durch.
Wenn beim Durchführen eines In-Place-Upgrades mehrere Domänen in der Quelle vorhanden sind, ruft das Installationsprogramm das Upgrade-Tool auf, obgleich der Prozess abgebrochen wird. Dieses Problem tritt auf, wenn der Aufruf im GUI-Modus erfolgt.
Führen Sie das In-Place-Upgrade im CLI-Modus durch, und beenden Sie den Vorgang, wenn Sie vom Installationsprogramm aufgefordert werden, am Ende des Installationsprozesses das Upgrade-Tool auszuwählen. Domänen, die im Domänenverzeichnis vorhanden sind, werden dabei nicht gelöscht. Das Upgrade-Tool sollte manuell über das Verzeichnis bin aufgerufen werden.
Erstellen Sie beim In-Place-Upgrade im GUI-Modus eine Sicherung der Domänen im Domänen-Root-Verzeichnis, um den Verlust dieser Domänen im Installationsprozess zu verhindern. Beenden Sie den Vorgang am Ende des Installationsprozesses, wenn Sie vom Installationsprogramm zum Aufrufen des Upgrade-Tools aufgefordert werden. Kopieren Sie die gesicherten Domänen in das Domänenverzeichnis, wenn diese verloren gegangen sind. Starten Sie das Upgrade-Tool manuell, um die Aktualisierung durchzuführen.
Beim Upgrade von AS 8.2 auf 9.1 wird das Master-Passwort aus der 8.2-Installation in der 9.1-Installation nicht geerbt. Dies führt anschließend bei der nächsten Admin-Anmeldung zu einem Authentifizierungsfehler.
Das standardmäßige Admin-Passwort in Application Server 9.1 lautet changeit. Um nach dem Upgrade von 8.2 Probleme bei der Anmeldung am 9.1-Server zu vermeiden, führen Sie einen der folgenden Schritte aus:
Ändern Sie das Admin-Passwort aus Version 8.2 vor dem Upgrade in changeit.
Akzeptieren Sie das standardmäßige Admin-Passwort während des Upgrades nicht, sondern geben Sie explizit das gewünschte Passwort ein.
Melden Sie sich unter Verwendung des Standardpassworts an 9.1 an, und ändern Sie dieses Passwort umgehend.
Das Upgrade-Tool aktualisiert keine Datenbanken oder Datenbanktabellen. Diese Option wird auch in zukünftigen Versionen nicht unterstützt. Die Konfigurationen der Ressourcenreferenzen werden übermittelt, und Application Server sollte weiterhin mit den ursprünglichen Datenbanken und Tabellen funktionieren. Wenn Sie die Datenbanken oder Übertragungsdatenbanktabellen ändern möchten, verwenden Sie die Tools, die mit der verwendeten Datenbank funktionieren.
Führen Sie zur Migration des MQ-Speichers die folgenden Schritte aus:
Führen Sie die folgenden Schritte aus, NACHDEM AS 8.2 heruntergefahren und NACHDEM das AS9.1-Upgrade-Tool ausgeführt, jedoch BEVOR AS9.1 ERSTMALIG gestartet wurde. Wenn Sie AS 9.1 nach der IFR-Installation/Aktualisierung bereits gestartet haben, führen Sie diese Schritte NICHT aus, da sie die Stabilität des MQ-Nachrichtenspeichers gefährden können.
Kopieren Sie das gesamte Unterverzeichnis domains/domain1/imq aus dem AS 8.x domains-Verzeichnis in das AS 9.1-Verzeichnis domains.
Stellen Sie sicher, dass der Besitzer des Verzeichnisses und der Dateien mit dem Benutzer übereinstimmt, der Application Server ausführen wird.
Nachdem Ausführen der oben stehenden Schritte kann Application Server 9.1 gestartet werden, und der MQ-Speicher im Application Server 9.1-Verzeichnis domains wird aus dem JES5 U1-Format in das MQ 4.1-Format migriert. Beachten Sie, dass der ursprüngliche JES5 U1 MQ-Speicher unter AS 8.2 beibehalten wird und nicht durch diese Prozedur oder MQ4.1 beim Start von AS 9.1 geändert wird.
Beim Upgrade von JES5 (Application Server 8.2) auf Application Server 9.1 funktioniert das Portal Server Community-Beispiel nicht mehr, und es werden eine Vielzahl von javax.faces.application.ApplicationFactory-Fehlern angezeigt.
Die Aktualisierung von Application Server 8.2 auf 9.1 wird nicht unterstützt, wenn Application Server 8.2 mit JES5 Portal Server installiert wurde. Portal Server muss vor dem Upgrade von Application Server auf 9.1 auf Java ES 5 Update 1 aktualisiert werden.
Bei der Aktualisierung von Application Server 8.2 auf 9.1 über das IFR-Installationsprogramm auf Linux-Plattformen kann die Option JDK installieren ausgewählt werden, nach der erfolgreichen Fertigstellung der Installation funktionieren die meisten JES-Komponenten jedoch nicht.
Dieses Problem betrifft ausschließlich die IFR-Installation von Application Server 9.1 auf Linux-Plattformen und tritt nur auf, wenn die Option JDK installieren ausgewählt ist. Verknüpfen Sie /usr/jdk/entsys-j2se nach der Installation umgehend manuell mit dem Verzeichnis /usr/java/jdk1.5.0_12 , um dieses Problem zu umgehen.
Bei der Aktualisierung von Application Server 9.1 IFR unter Windows, wird die In-Place-Sicherung nicht ordnungsgemäß in die asupdate.bat-Formularwerte integriert. Genau gesagt, wenn Sie in einem ASupdate.bat-GUI-Bildschirm falsche Informationen eingeben und auf Weiter klicken, versucht das Upgrade-Installationsprogramm zu ermitteln, ob es sich um ein In-Place-Upgrade handelt. Falls ja, wird domain1 vor dem Upgrade in ein Sicherungsverzeichnis verschoben. Im Verlauf des Upgrades wird eine Fehlermeldung aufgrund dieser falschen Informationen angezeigt. Wenn Sie versuchen, den Fehler umgehend zu beheben, wird ein Pfadfehler ausgegeben, da domain1 bereits verschoben wurde.
Ändern Sie das Quellverzeichnis entweder in das Verzeichnis domain1_ {Zeitstempel} unter {aktueller Quellpfad}/backup, oder beenden Sie das Installationsverzeichnis über die Schaltfläche Abbrechen, und starten Sie den Vorgang erneut.
(Nur Windows) Wenn eine frühere Version von Application Server unter Verwendung von speziellen Zeichen oder Kurznamen im DOS-Stil im Programmverzeichnispfad installiert wurde, schlagen anschließende In-Place-Upgrades auf Application Server 9.1 fehl, wenn dieselben Verzeichnispfadnamen verwendet werden.
Beispiel: Application Server 8.2 wurde in einem der folgenden Verzeichnisse installiert:
C:\Programme (x86)\dirs\appserver c:\progra~2\dirs\appserver |
Der Versuch, ein In-Place-Upgrade auf 9.1 durchzuführen, schlägt fehl, da das Installationsprogramm die Kurznamen oder speziellen Zeichen nicht in das erforderliche lange Namensformat konvertieren kann.
Es wird dringend davon abgeraten, Application Server unter Verwendung eines Pfadnamens mit speziellen Zeichen oder Abkürzungen für Kurznamen im DOS-Stil (z. B. progra~2) zu installieren, da dies die anschließende Installation von Upgrades verhindert. Wenn eine solche Installation vorhanden ist, installieren Sie sie vor dem Upgrade entweder unter Verwendung von langen Pfadnamen erneut, oder installieren Sie die neue Version von Application Server in einem vollständig neuen Verzeichnis.
Nach einem Application Server-Upgrade funktioniert das <jsp:forward>-Tag in Authenticate.jsp nicht wie erwartet. Der <jsp:forward>-Aufruf führt zu einem Fehler in den Serverprotokollen, und in der WebUI wird eine leere Seite angezeigt. Das Problem ist, dass <jsp:forward> in Authenticate.jsp ein Seitenattribut wie <jsp:forward page="${redirectPage}"/> erfordert, der übergebene Wert jedoch ein relativer Pfad wie /registry/thin/{pagename}.jsp ist. Dieser funktioniert selbst dann nicht, wenn Authenticate.jsp eine reine JSP-Seite ist.
Verwenden Sie nach dem Upgrade von Application Server das asadmin-Tool, um die folgenden Befehle zum Festlegen des <auth-realm> in domain.xml auszuführen:
Wechseln Sie zu <AS9.1-Installationsverzeichnis>/bin, und führen Sie den folgenden Befehl aus:
./asadmin delete-auth-realm --host localhost --port 6489 certificate |
Dadurch wird das alte auth-realm-Zertifikat entfernt (sofern vorhanden).
Führen Sie den folgenden Befehl aus:
./asadmin create-auth-realm --terse=false --echo=true --interactive=true \ --user admin --host localhost --port 6489 --classname \ com.sun.enterprise.security.auth.realm.certificate.CertificateRealm \ --property assign-groups=have.client.cert certificate |
Dadurch wird der neue <auth-realm> mit der assign-groups-Eigenschaft erstellt.
Halten Sie die Application Server-Domäne registry an, und starten Sie sie neu.
Beim Ausführen der asupgrade-GUI in einer anderen Sprache als Englisch ist keine lokalisierte Version der Online-Hilfe für die GUI vorhanden.
Gegenwärtig ist keine Lösung verfügbar. Die Lokalisierung der Online-Hilfe ist für alle Zielsprachen neben Englisch geplant.
In diesem Abschnitt werden die bekannten Probleme mit Webcontainern sowie ihre Lösungen beschrieben.
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.
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. |
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.
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.
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.
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) |
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> |
Alle Einstellungen verhindern, dass ant einen neuen Prozess für die javac -Kompilierung erzeugt.
Sun Java System Application Server 9.1 fügt Unterstützung für die über das auth-passthrough-Plug-In bereitgestellte Funktionalität hinzu, das mit Sun Java System Application Server Enterprise Edition 7.1 verfügbar ist. In Application Server 9.1 ist die auth-passthrough-Plug-In-Funktion jedoch nicht identisch konfiguriert.
Die auth-passthrough-Plug-In-Funktion in Application Server Enterprise Edition 7.1 war in zweistufigen Bereitstellungsszenarien nützlich, in denen Folgendes zutrifft:
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 Application Server Enterprise Edition 7.1 konnte die auth-passthrough-Plug-In-Funktion in der Application Server-Proxy-Instanz konfiguriert werden, um die Informationen des Remote-Cients direkt für die auf dem Client bereitgestellten Anwendungen verfügbar zu machen (als hätte die Application Server-Proxy-Instanz die Anforderung direkt empfangen, und nicht über einen Webserver, auf dem das service-passthrough-Plug-In ausgeführt wird.
In Application Server 9.1 kann die auth-passthrough-Funktion aktiviert werden, indem Sie die Eigenschaft authPassthroughEnabled des <http-service>-Elements in domain.xml wie folgt auf TRUE setzen:
<property name="authPassthroughEnabled" value="true"/> |
Die zu berücksichtigenden Sicherheitsaspekte der auth-passthrough-Plug-In-Funktion in Application Server Enterprise Edition 7.1 gelten gleichermaßen für die authPassthroughEnabled-Eigenschaft in Application Server 9.1. Da über authPassthroughEnabled Informationen außer Kraft gesetzt werden können, die möglicherweise für Authentifizierungszwecke verwendet werden (z. B. die IP-Adresse, von der die Anforderung stammt, oder das SSL-Clientzertifikat), ist es äußerst wichtig, dass sich nur vertrauenswürdige Clients oder Server mit einer Application Server 9.1-Instanz verbinden können, deren authPassthroughEnabled-Eigenschaft auf TRUE gesetzt 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.
Dieses Problem tritt nur bei Verwendung von Sun Java System Web Server mit Application Server 9.1 und Lastenausgleich auf einem Linux-System auf. In diesem Fall kann Web Server nach der Installation von Application Server und einer Lastenausgleichskomponente möglicherweise nicht gestartet werden, da ein Konflikt zwischen libicui18n.so.2 und libicuuc.so.2 vorliegt. Diese Bibliotheken sind sowohl in /opt/sun/private/lib als auch in /opt/sun/appserver/lib vorhanden.
Die richtigen Bibliotheken, die verwendet werden sollten, befinden sich im Verzeichnis /opt/sun/appserver/lib , da lbplugin mit diesen Bibliotheken erstellt wird. Nachdem die beiden Bibliotheken aus /opt/sun/private/lib entfernt wurden, sollte Web Server ohne Probleme gestartet werden können.
Alternativ, wenn Sie die Bibliotheken nicht aus /opt/sun/private/lib löschen möchten, können Sie /opt/sun/appserver/lib vor /opt/sun/private/lib in LD_LIBRARY_PATH im Web Server-Skript startserv einfügen; Das heißt, Sie ersetzen Folgendes:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}: /opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib"; export LD_LIBRARY_PATH |
durch:
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="/opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib: ${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH |
In diesem Abschnitt werden die bekannten Probleme mit Webcontainern sowie ihre Lösungen beschrieben.
Beim Ausführen von JAX–WS-Tests mit JDK 1.6 (im Lieferumfang von Java EE SDK b33d enthalten) treten möglicherweise Problem auf. Die Tests werden umgehend mit der folgenden Fehlermeldung abgebrochen:
[wsimport] Ausnahme in Thread "main" java.lang.NoClassDefFoundError: \ com/sun/tools/ws/WsImport |
Dieser Fehler tritt auf, obwohl die webservices-tools.jar-Datei folgende Elemente enthält: com/sun/tools/ws/WsImport.class, com/sun/tools/ws/ant/WsImport.class und com/sun/tools/ws/ant/WsImport2.class. Darüber hinaus funktioniert derselbe Testarbeitsbereich unter Verwendung von 1.5.0-10 JDK problemlos.
Kopieren Sie die Datei webservices-api.jar vor dem Ausführen der JAX-WS-Tests in das Verzeichnis $JAVA_HOME/jre/lib/endorsed .
JAXR verwendet SAAJ, um SOAP-Meldungen an die Registrierung zu senden. Wenn nicht IFR verwendet wird, befinden sich die SAAJ-Klassen impl unter lib/webservices-rt.jar . Bei Einsatz von IFR befinden sich die SAAJ-Klassen weiterhin unter lib/webservices-rt.jar . Darüber hinaus befindet sich saaj-impl.jar im Verzeichnis /usr/share/lib. Diese JAR-Datei wird von Application Server verwendet und hat Vorrang vor Klassen aus webservices-rt.jar. Diese JAR-Datei verfügt nicht über die erforderlichen Sicherheitsberechtigungen, um SOAP-Meldungen an die Web Services-Registrierung zu senden. Das Paket sollte so geändert werden, dass den JAR-Dateien unter /usr/share/lib Berechtigungen zugewiesen werden oder dass keine Abhängigkeit von den JAR-Dateien in /usr/share/lib besteht.
Fügen Sie der server.policy-Datei Folgendes hinzu:
grant codeBase "file:/usr/share/lib/saaj-impl.jar" { permission java.security.AllPermission; }; |