test

Sun Java System Application Server Enterprise Edition 8.2 - Versionshinweise für Microsoft Windows

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 Application Server Enterprise Edition 8.2 erläutert. Wenn für ein Problem keine spezielle Plattform angegeben ist, betrifft es alle Plattformen. Diese Informationen sind in die folgenden Abschnitte unterteilt:

Administration

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

Die Load Balancer-Funktion wird in Verbindung mit dem Application Server in "Automatisch während der Installation konfigurieren" nicht unterstützt (6463858)

Die Load Balancer-Funktion wird in Verbindung mit Application Server in "Automatisch während der Installation konfigurieren" nicht unterstützt.

Lösung:Die Load Balancer-Funktion kann nach der Installation von Application Server konfiguriert werden.

Hinweis –

Application Server und Web Server müssen auf dem System installiert sein, um die Load Balancer-Funktion zu konfigurieren.

    Um die Load Balancer-Funktion zu konfigurieren, führen Sie folgende Schritte durch:

  1. Setzen Sie im Verzeichnis HKEY_LOCAL_MACHINE -> Sun Microsystem -> EntSys -> Installer -> Application Server den Wert von IS_LB auf "true" und von Cfgr_LB auf "false".

  2. Wechseln Sie in das Verzeichnis setup.

    cd JavaES-Install-Dir\setup\ 


    
    		

    

    


    3. 

  3. 

    Führen Sie die Stapeldatei ASConfigure.bat aus.
    



    4. 

  4. 

    Befolgen Sie die Anweisungen und geben Sie den richtigen Wert ein.
    


    
Hinweis – 

    Als AS_LB-Plugin geben Sie "Sun Java System Web Server" ein [Obligatorisch], da es sich dabei um das einzige unter Java ES 5 unterstützte Plugin handelt.
    


    



    5. 

  5. 

    Starten Sie das System neu.
    



    6. 



Das package-appclientwird nicht ausgeführt, wenn domain1 nicht vorhanden ist (Nr. 6171458)


In JavaES-Install-Dir \lib\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 Variable AS_ACC_CONFIG nicht entsprechend der neuen Domäne aktualisiert, sodass die Ausführung des Skripts package-appclient fehlschlägt.


Lösung


Gehen Sie folgendermaßen vor:



Durch Installieren des Load Balancing Plugins wird ein vorhandenes Plugin überschrieben (Nr. 6172977)


Wenn Sie das Load Balancing Plugin in einer Application Server-Installation installieren, bei der bereits ein Load Balancing Plugin installiert wurde (z. B. unter 7.1EE), so wird jeder vorhandene Load Balancer vom 8.2 EE-Plugin automatisch ersetzt, selbst wenn Sie eine neue Serverinstanz erstellt haben, unter der Sie das Plugin ausführen. 


Die Plugin-Dateien werden standardmäßig im Verzeichnis install_dir /plugins/lbplugin installiert. Das bedeutet, das nur eine Version eines Plugins mit einer Application Server-Installation verwendet werden kann. Beachten Sie, dass das Konsoleninstallationsprogramm zwar eine Meldung ausgibt, durch die angegeben wird, dass eine Deinstallation erfolgt; diese Meldung kann jedoch leicht übersehen werden.


Lösung


Dieses Problem tritt nicht bei allen Benutzern auf. Wenn das Problem bei Ihnen auftritt, müssen Sie die alte Installation von Application Server entfernen und eine Neuinstallation durchführen. (Führen Sie keine Aufrüstungsinstallation durch.) 


Mehrere Änderungen im Skript asadmin in Java ES 3 Application Server 8.2 im Vergleich zu Java ES 2 Application Server 7 (Nr. 6189433, 6189436)


Am Befehl asadmin wurden in Application Server 8.2 gegenüber Application Server 7 und kompatiblen Versionen mehrere Änderungen vorgenommen. Beispielsweise lautet in Application Server 7 und kompatiblen Versionen der Befehl zum Starten einer Serverinstanz:









asadmin start-instance





In Version 8.2 lautet der entsprechende Befehl:









asadmin start-domain --user admin domain1





In den folgenden Dokumenten finden Sie umfassende Informationen zur aktuellen Syntax für den Befehl asadmin:



Standardports in Application Server geändert (Nr. 6198555)


Bei der Aufrüstung auf Java ES 5 Application Server 8.2 von Java ES 2 Application Server 7 und kompatiblen Versionen können Inkompatibilitäten oder Fehler auftreten, da sich die Standardports geändert haben.


Gesicherte Domäne kann nicht unter einem anderen Namen wiederhergestellt werden. (Nr. 6196993)


Das Spiegeln einer Domäne innerhalb derselben Application Server-Installation ist mit den Befehlen backup-domain und restore-domain  nicht möglich, da die Domäne nicht unter einem anderen Namen wiederhergestellt werden kann, auch wenn der Befehl asadmin restore-domain eine Option für das Umbenennen von Domänen zur Verfügung stellt. Die gesicherte Domäne kann zwar umbenannt werden, die Ausführung der umbenannten Domäne schlägt jedoch fehl, da die Einträge in der Konfiguration der Domäne nicht geändert wurden und  startserv und  stopserv den ursprünglichen Domänennamen in den Pfadangaben 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.2 funktionieren nur für die Sicherung und Wiederherstellung derselben Domäne auf demselben Computer.


Das Starten von Application Server mit einem zusätzlichen JMX-Agenten wird nicht unterstützt (Nr. 6200011)


J2SE 1.4., 5.0 und kompatible Versionen können auf Application Server konfiguriert werden. In J2SE 5.0 ermöglicht eine plattformeigene Funktion das Starten eines JMX-Agenten. Um diesen Agenten 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 VM von Application Server gestartet. Dieser Vorgang hat unerwünschte Auswirkungen auf die Verwaltungsfunktionen, sodass die Benutzeroberfläche und Befehlszeilenschnittstelle von Application Server nicht einwandfrei arbeiten. Diese Probleme werden durch Konflikte zwischen dem integriertenjmx-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 Connector Server wiederverwenden.


Wird der Server gestartet, so wird eine Zeile ähnlich der im nächsten Abschnitt dargestellten Zeile in der Datei server.log angezeigt. Sie können eine Verbindung zum dort angegebenen JMXServiceURL  herstellen und dieselben Management- und 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: Here is the JMXServiceURL for the
JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
rmi-jmx-connector]. This is where the remote administrative clients should
connect using the JSR 160 JMX Connectors.|#]


Weitere Informationen finden Sie im  Sun Java System Application Server 8.2 Administration Guide.


Load Balancer-Konfigurationsdatei konnte nicht mit dem Endpunkt-URL eines Webservice erstellt werden (Nr. 6236544, 6275436)


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.


Lösung


    

  1. 

    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"/>
    
    		

    

    


    2. 

  2. 

    Ersetzen Sie den Wert context-root-name mit dem
Kontext-Rootnamen des Webservice, der als EJB offengelegt wurde.
    



    3. 



Java Home-Einstellung in der Konfiguration ohne Wirkung (Nr. 6240672)


Application Server-Domänen und -Server verwenden nicht das JDK, auf das das Attribut  java-home des Elements java-config der zugehörigen Konfiguration verweist.


Lösung


Das von den Application Server-Prozessen für alle Domänen in einer bestimmten Serverinstallation verwendete JDK wird in der Datei appserver-installation-dir /config/asenv.conf festgelegt. Die Eigenschaft AS_JAVA  in dieser Datei bestimmt das verwendete JDK und wird zum Installationszeitpunkt festgelegt. Wenn nach Abschluss der Installation ein anderes JDK von den Application Server-Prozessen verwendet werden soll, kann dieser Wert so geändert werden, dass er auf ein anderes JDK verweist. Beachten Sie, dass alle Domänen in dieser Installation von dieser Änderung betroffen sind.


Hinweis – 
Manuelle Änderungen an der Datei asenv.conf werden nicht auf ihre Gültigkeit überprüft. Sie sollten bei ihrer Änderung daher mit besonderer Sorgfalt vorgehen. Die Mindestanforderungen an die JDK-Version bei der Bearbeitung des Werts für AS_JAVA finden Sie in der Produktdokumentation.




Application Server-Neustart unter Verwendung von sun-appserv-admin  führt zu einem LoginException-Fehler (Nr. 6288893)


Dieses Problem wird durch einen falschen Wert für %CONFIG_HOME% verursacht. 


Lösung


    

  1. 

    Benennen Sie die bestehende Datei asant in asant.bak um. 
    



    2. 

  2. 

    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 asant um.
    



    3. 

  3. 

    Bearbeiten Sie die gerade kopierte Datei as_install/bin/asant , wobei Sie das %CONFIG_HOME%-Token durch den Wert as_install /config ersetzen.
    



    4. 

  4. 

    Falls manuelle Änderungen an der ursprünglichen asant.bak-Datei vorgenommen wurden, führen Sie diese in die neue asant-Datei zusammen.
    



    5. 



Datei .asadmintruststore wird nicht in der  Application Server-Dokumentation beschrieben (Nr. 6315957)


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



Domäne startet nicht, wenn das  create-domain-Masterpasswort Sonderzeichen enthält (Nr. 6345947)


Die Domäne startet nicht, wenn das Masterpasswort der Domäne ein Prozentzeichen (%) enthält. 


Lösung


Das Masterpasswort der Domäne sollte kein Prozentzeichen enthalten (%). Diese Lösung gilt für das Erstellen einer neuen Domäne bzw. für das Ändern des Masterpassworts einer bestehenden Domäne.


Die Änderungen an der Load Balancer-Konfiguration in  magnus.conf und obj.conf werden überschrieben (Nr. 6394181)


Nach dem Erstellen eines sicheren http-listener und der Installation von  lbplugin werden die Dateien magnus.conf und obj.conf unter dem Verzeichnis webserver_instance_dir/config bearbeitet und die Inhalte von lbplugin werden entfernt.


Das Installationsprogramm bearbeitet die Konfigurationsdateien magnus.conf und obj.conf  in Application Server im Rahmen der Installation des Load Balancer-Plugins. Wenn Sie sich bei der Application Server-Administratorkonsole anmelden und versuchen, die Instanzenkonfiguration für die Instanz zu ändern, auf der der Load Balancer installiert wurde, gibt Application Server eine Warnmeldung aus, die besagt, dass eine manuelle Bearbeitung in der Konfiguration gefunden wurde. Diese Warnung bezieht sich jedoch in Wirklichkeit auf die vom Installationsprogramm vorgenommenen Änderungen.


Lösung


Vergewissern Sie sich, dass die vom Installationsprogramm vorgenommenen Änderungen nicht überschrieben wurden.


Anwendungsclient


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


JAR-Bibliothek im Archiv des Anwendungsclients überschreibt die MANIFEST-Datei (Nr. 6193556)


Wenn die Client-JAR eine JAR-Datei der obersten Ebene enthält (hier reporter.jar) und Sie die Client-JAR bereitstellen, überschreibt die MANIFEST-Datei dieser JAR die MANIFEST-Datei der Client-JAR.


Lösung


Keine.


Technologien für dynamische Inhalte, wie beispielsweise CGI-bin und SHTML-Funktionen, werden nicht unterstützt (Nr. 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.


Anwendungen, die die TRANSACTION_SERIALIZABLE-Isolationsebene zusammen mit im Paket enthaltenen Sun-Treibern mit Microsoft SQL Server verwenden, reagieren nicht (Nr. 6165970)


Dieses Problem kann auftreten, wenn eine vorbereitete Aktualisierungsanweisung verwendet wird und zwei Transaktionen parallel ausgeführt werden und eine der Transaktionen rückgängig gemacht wird. 


Lösung


Um eine Isolationsebene für eine Verbindung zu setzen, erstellen Sie das entsprechende Verbindungspool auf derselben Isolationsebene. Weitere Informationen über die Konfiguration von Verbindungspools erhalten Sie im Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.



PreparedStatement-Fehler (Nr. 6170432)


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, um sicherzustellen, dass 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 unter Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.


Beschreibung 2


Im Zusammenhang mit dem PreparedStatement-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 beispielsweise 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 setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Anweisungen finden Sie im Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.


Konnektoren


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


Nach dem Neustart einer DAS-Instanz kann die Bereitstellung des Konnektormoduls nicht aufgehoben werden, wenn die Option "Cascade" auf False gesetzt ist (Nr. 6188343)


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


Starten Sie die DAS-Instanz neu. Verwenden Sie die Cascade-Funktion zum Aufheben der Bereitstellung (setzen Sie die cascade-Option auf true), um die Bereitstellung eigenständiger und eingebetteter Konnektoren aufzuheben. 


JMS create-jms-resource; CLI legt die Standardwerte falsch fest (Nr. 6294018)


Da Sie die minimale und maximale Poolgröße nicht angeben können, wenn Sie mit dem Befehl asadmin create-jms-resource über die Befehlszeile eine neue JMS-Ressource erstellen, sollte der Befehl asadmin die Ressource unter Verwendung der Standardwerte für die Poolgröße (Minimum  8, Maximum 32) erstellen. Stattdessen führt die Erstellungen der Ressource über die Befehlszeile zu einer standardmäßigen minimalen bzw. maximalen Poolgröße von 1 bzw. 250. 


Lösung


Bearbeiten Sie nach der Erstellung einer JMS-Ressource über die Befehlszeile die Werte für die minimale und maximale Poolgröße mithilfe der  Verwaltungskonsole.


Dokumentation


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


Javadoc-Inkonsistenzen


Die Javadoc verschiedener AMX-Schnittstellen und -Methoden fehlen oder sind nicht korrekt:



Gebündeltes ANT führt zum Ausnahmefehler java.lang.NoClassDefFoundError  (Nr. 6265624)


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 Application Server wird nicht empfohlen.


Dokumentation für Protokollieroptionen inkorrekt (Nr. 6463965)


Im Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide stehen fälschlicherweise folgende Angaben zu Protokolloptionen:




Die Administrations-GUI bietet die folgenden beiden Protokollieroptionen:




    

  • 

    
Option 1 – Protokollierung von stdout ( System.out.print)-Inhalten im Ereignisprotokoll
    



    • 

  • 

    
Option 2 – Protokollierung von stderr ( System.err.print)-Inhalten im Ereignisprotokoll
    



    • 





Diese Protokolloptionen sind in Application Server Enterprise Edition
 8.2 nicht mehr verfügbar.


In Konflikt stehende Informationen zur HTTP-Dateicache-Funktion in Application Server 8.2 (Nr. 6474799)


In der Application Server Enterprise Edition
 8.2-Dokumentation wird eine HTTP-Dateicache-Funktion besprochen. Und zwar unter HTTP File Cache in Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide. Diese Funktion wurde jedoch nicht in Application Server Enterprise Edition
 8.2 aufgenommen. Beachten Sie, dass diese Funktion in Application Server 9.0 erneut eingeführt wurde.


Hochverfügbarkeit


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



hadbm set prüft Ressourcenverfügbarkeit nicht (Festplatte und Arbeitsspeicher) (Nr. 5091280)


Wenn Sie mit hadbm set den Hauptspeicher oder die Puffergröße des Geräts ändern, prüft das Verwaltungssystem die Ressourcenverfügbarkeit beim Erstellen von Datenbanken und beim Hinzufügen von Knoten. Es wird jedoch nicht vom System überprüft, ob ausreichende Ressourcen zur Verfügung stehen, wenn der Arbeitsspeicher oder die Puffergröße geändert wird.


Lösung


Stellen Sie sicher, dass auf allen Hosts genügend freier Festplatten- oder Arbeitsspeicher zur Verfügung steht, bevor Sie die Konfigurationsattribute devicesize bzw. buffersize erhöhen.


Heterogene Pfade für packagepath  nicht unterstützt (Nr. 5091349)


Es ist nicht möglich, ein und dasselbe Software-Paket unter demselben Namen in verschiedenen Pfaden auf unterschiedlichen Hosts zu registrieren. 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.



createdomain schlägt möglicherweise fehl (Nr. 6173886, 6253132)


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.





Falls nicht anders konfiguriert verwenden die Management-Agenten 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. Zum Beispiel 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, die durch repository.dr.path in der Konfigurationsdatei des Management-Agenten identifiziert werden. Der Löschvorgang muss auf allen Hosts durchgeführt werden, bevor die Agenten mit einer neuen Konfigurationsdatei erneut gestartet werden.


Verzeichnisse müssen nach dem Löschen einer HADB-Instanz bereinigt werden (Nr. 6190878)


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.



clu_trans_srv kann nicht unterbrochen werden (Nr. 6249685)


Durch einen Bug In der 64-Bit-Version von Red Hat Enterprise Linux 3.0 wird der Prozess clu_trans_srv gezwungen, in einem Modus zu enden, 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.



hadbm unterstützt keine Passwörter, die Großbuchstaben enthalten (Nr. 6262824)


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.


Durch hadbm/ma wird eine fehlerhafte Fehlermeldung ausgegeben, wenn ein Sitzungsobjekt die Zeitsperre überschritten hat und beim Management-Agenten gelöscht wurde (Nr. 6275103)


Mitunter kann es durch einen Ressourcenkonflikt auf dem Server dazu kommen, dass der Management-Client getrennt wird. Bei der erneuten Verbindungsherstellung wird unter Umständen die irreführende Fehlermeldung "hadbm:Fehler 22184: Zum Herstellen der Verbindung mit dem Management-Agenten ist ein Passwort erforderlich" zurückgegeben.


Lösung


Überprü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.


Der Management-Agent sollte keine besonderen Schnittstellen verwenden (Nr. 6293912)


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 eingibt, durch den Hostnamen anstelle von IP-Adressen aufgerufen werden. 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 ausdrücklich die IP-Adressen angeben, indem Sie die DDN-Notation verwenden.


Reassemblierungsfehler unter Windows (Nr. 6291562)


Auf der Windows-Plattform kann es unter Umständen bei bestimmten Konfigurationen zu einer großen Anzahl von Reassemblierungsfehlern im Betriebssystem kommen. Das Problem trat bei Konfigurationen von mehr als 20 Knoten auf, als mehrere Tabellenscans (select *) gleichzeitig ausgeführt wurden. Symptome hierfür können sein, dass die Transaktionen häufig abbrechen, die Reparatur oder Wiederherstellung lange Zeit in Anspruch nimmt 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 811003 der Microsoft-Supportseiten.


Bei der Ausführung von hadbm start db_name wird ein Teil des eingegebenen Passworts unmaskiert angezeigt (Nr. 6303581, 6346059, 6307497)


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. Das Passwort sollte stets maskiert sein.


Lösung


Legen Sie die Passwörter in eigenen Passwortdateien ab (die seit Application Server 8.1 empfohlene Methode) und beziehen Sie sich auf diese Dateien mit den Optionen --adminpassword  bzw. --dbpasswordfile.


Installation


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


Java Enterprise System 5-Installationsprogramm für minimalen Application Server 8.x-Lastenausgleich lässt sich nicht ordnungsgemäß installieren (Nr. 6478047)


Apache und IIS können durch das Java ES 5-Installationsprogramm nicht konfiguriert werden. Sie müssen Apache und IIS auf der Windows-Plattform manuell konfigurieren.


Lösung


Um Load Balancer Apache oder IIS zu konfigurieren, führen Sie folgende Schritte durch:


    

    
So konfigurieren Sie Apache 2.x:

    


  1. 

    Installieren Sie Apache 2.x.
    


    Apache wird im Verzeichnis  APDIR=C:\Apache2\Apache2 installiert.
    



    2. 

  2. 

    Installieren Sie JES5 mit minimaler Installation.
    


    Deaktivieren Sie alle Komponenten außer Load Balancer. Java ES 5 wird im Verzeichnis JES5DIR=C:\Program Files\Sun\JavaES5 installiert. 
    


    Der
    



    3. 

  3. 

    Erstellen Sie die Verzeichnisse resource und errorpages im Verzeichnis Apache2. 
    


    
mkdir %APDIR%\modules\resource

    


    
 mkdir %APDIR%\modules\errorpages

    



    4. 

  4. 

    Kopieren Sie die Ressourcendatei in das Verzeichnis resource.
    


    
cd %APDIR%\modules\resource

    


    
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\LBPlugin*.res .

    



    5. 

  5. 

    Kopieren Sie die Load Balancer-DLL in das Verzeichnis modules. 
    


    
cd %APDIR%\modules 

    


    
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\mod_loadbalancer.dll .

    



    6. 

  6. 

    Kopieren Sie die Vorlage errorpages in das Verzeichnis  errorpages.
    


    
cd %APDIR%\modules\errprpages 

    


    
copy %JES5DIR%appserver\lib\webserver-plugin\windows\iws\errorpages .

    



    7. 

  7. 

    Kopieren Sie die Load Balancer-Vorlage und die andere DTD in das Apache-Verzeichnis  config.
    


    
cd %APDIR%\config

    


    
copy %JES5DIR%\appserver\lib\install\templates\loadbalancer.xml.template .

    


    
copy %JES5DIR%\appserver\lib\dtds\sun-loadbalancer* . 

    



    8. 

  8. 

    Erstellen Sie eine Sicherung der Datei httpd.conf.
    


    
cd %APDIR%\config

    


    
copy httpd.conf httpd.conf.orig

    



    9. 

  9. 

    Bearbeiten Sie die Datei httpd.conf.
    


    Hängen Sie folgende Zeilen an die Datei httpd.conf an:
    



    ##BEGIN EE LB Plugin Parameters
LoadModule apachelbplugin_module modules/mod_loadbalancer.dll
<IfModule mod_apache2lbplugin.cpp>
		config-file "C:\Apache2\Apache2/conf/loadbalancer.xml"
		locale en
</IfModule>
<VirtualHost 10.12.8.107>
DocumentRoot "C:\Apache2\Apache2/htdocs"
ServerName vm07
</VirtualHost>
##END EE LB Plugin Parameters
    



    10. 

  10. 

    Ersetzen Sie C:\Apache2\Apache2 durch das Vereichnis  %APDIR%.
    


    Ersetzen Sie darüber hinaus die Verzeichnisse "IP", "ServerName" und "DocumentRoot".
    



    11. 

  11. 

    Erstellen Sie ein neues sec_db_files-Verzeichnis im Verzeichnis %APDIR%. 
    


    
cd %APDIR%

    


    
mkdir sec_db_files 

    



    12. 

  12. 

    Kopieren Sie den NSS-Schlüsselspeicher in das Verzeichnis %APDIR%\sec_db_files. 
    


    
cd %APDIR%\sec_db_files

    


    
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\iis\*.db .

    



    13. 

  13. 

    Setzen Sie "PATH" so, dass er die erforderlichen Bibliotheken enthält. 
    


    Fügen Sie den folgenden zusätzlichen Pfad hinzu:
    


    
PATH %JES5DIR%\share\lib;%JES5DIR%\appserver\lib;%JES5DIR%\appserver\bin 

    



    14. 

  14. 

    Ersetzen Sie %JES5DIR% durch das eigentliche Java ES 5-Verzeichnis.
    



    15. 

  15. 

    Fügen Sie in der Systemumgebung NSPR_NATIVE_THREADS_ONLY mit "value 1" hinzu.
    



    16. 

  16. 

    Starten Sie neu und testen Sie Apache 2 (nach Konfiguration von loadbalancer.xml ). 
    



    17. 



    

    
So konfigurieren Sie IIS LBPlugin:

    


  1. 

    Erstellen Sie das Verzeichnis sun-passthrough im Verzeichnis c:\inetpub\wwwroot .
    


    
cd c:\inetpub\wwwroot

    


    
mkdir sun-passthrough

    



    2. 

  2. 

    Erstellen Sie die Verzeichnisse errorpages, resource und sec_db_files  im Verzeichnis c:\inetpub\wwwroot\sun-passthrough .
    


    
cd c:\inetpub\wwwroot\sun-passthrough 

    


    
mkdir errorpages

    


    
mkdir resources

    


    
mkdir sec_db_files

    



    3. 

  3. 

    Kopieren Sie die DLL-Dateien in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.dll c:\inetpub\wwwroot\sun-passthrough\

    



    4. 

  4. 

    Kopieren Sie die DTDs in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/dtds/sun-loadbalancer*.dtd c:\inetpub\wwwroot\sun-passthrough\

    



    5. 

  5. 

    Kopieren Sie die Datei sun-passthrough.properties in das Verzeichnis sun-passthrough .
    


    
copy <as_install_dir>/appserver/lib/webserver-plugin/iis c:\inetpub\wwwroot\sun-passthrough\

    



    6. 

  6. 

    Kopieren Sie die Sicherheitsdatenbankdateien in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.db c:\inetpub\wwwroot\sun-passthrough\sec_db_files\

    



    7. 

  7. 

    Kopieren Sie die Ressourcendateien in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/webserver-plugin/iws/*.res c:\inetpub\wwwroot\sun-passthrough\resource\

    



    8. 

  8. 

    Kopieren Sie die Fehlerseiten in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/webserver-plugin/iws/errorpages/*.html c:\inetpub\wwwroot\sun-passthrough\errorpages\

    



    9. 

  9. 

    Kopieren Sie die Vorlage loadbalancer.xml.example in das Verzeichnis sun-passthrough. 
    


    
copy <as_install_dir>/appserver/lib/install/templates/loadbalancer.xml.example c:\inetpub\wwwroot\sun-passthrough\

    



    10. 

  10. 

    Bearbeiten Sie die Datei sun-passthrough.properties.
    



    ##BEGIN EE LB Plugin Parameters
log-file = C:\InetPub\wwwroot\sun-passthrough\lb.log
### The valid options for different logging levels are FATAL, SEVERE, WARNING, INFO and FINE.
log-level = INFO
lb-config-file = C:\InetPub\wwwroot\sun-passthrough\loadbalancer.xml
##END EE LB Plugin Parameters
    



    11. 



Hinweis – 
Stellen Sie bei der Konfiguration von IIS6 sicher, dass Sie die Rechte so festlegen und zusätzliche Schritte so durchführen wie in der AS82-Dokumentation beschrieben. Möglicherweise müssen Sie den IIS6-Isolationsmodus auf IIS5-kompatibel setzen.




Das imq-Verzeichnis muss während der Installation erstellt werden. (Nr. 6199697)


Nachdem Sie Application Server Enterprise Edition unter Windows installiert haben, schlägt die Ausführung des Message Queue-Brokers beim Start fehl. Es wird eine Fehlermeldung angezeigt, die besagt, das das Verzeichnis drive:\as\domains\domain1\imq nicht vorhanden ist.


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


    

  1. 

    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
    
    		

    

    


    2. 



J2EE Tutorial


Zum Ausführen von J2EE 1.4 Tutorial auf Sun Java System Application Server Enterprise Edition
 8.2 führen Sie folgende Schritte aus:



Lifecycle-Verwaltung


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


Nach Ändern der ejb-timer-service-Eigenschaft tritt ein Fehler auf (ID 6193449)


Nachdem die ejb-timer-service-Eigenschaft  minimum-delivery-interval auf 9000 gesetzt wurde, führt ein Versuch, die  ejb-timer-service-Eigenschaft redelivery-interval-in-mills  auf 7000 zu setzen, dazu, dass der Befehl set fehlschlägt. Daraufhin wird die folgende Fehlermeldung angezeigt:


[echo] Doing admin task set
[exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-
Interval (7,000) should be greater than or equal to Minimum-delivery-
interval-in-millis (9,000)]
[exec] CLI137 Command set failed.



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.


Festlegen einer Debug-Anweisung für access.failure  führt dazu, dass das System beim Start von Application Server nicht mehr reagiert (Nr. 6180095)


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\>


Lösung


Keine. Setzen Sie dieses Flag nicht.


Geänderter Protokollspeicherort oder /Instanzspeicherort für Java ES 3 Application Server (Nr. 6189409)


Die Standardspeicherorte für Protokollierung und Serverinstanz haben sich in  Sun Java System 8.2 im Vergleich zu Version 7 und kompatiblen Versionen geändert.


Weitere Informationen finden Sie im Sun Java System Application Server Enterprise Edition 8.2 Administration Guide oder im Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide.


Message Queue


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


Erneuter JMS-Verbindungsaufbau in Timing-abhängigen Szenarien nicht erfolgreich abgeschlossen (Nr. 6173308, 6189645, 6198481, 6199510, 6208728)


Fehler beim erneuten Verbindungsaufbau in Timing-abhängigen Szenarien können durch verschiedene Probleme verursacht werden.


Lösung


Es gibt folgende Problemlösungen:



Das Verhalten des asynchronen Meldungs-Listener in appclient hat sich zwischen 8.0 und 8.1 Update 2 geändert (Nr. 6198465)


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 ältere 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.


Integration von Monitoring Framework in Application Server (6469302)


Bei der Beta-Version von Application Server wird Monitoring Framework nicht standardmäßig unterstützt.



Lösung 



    

    Um Monitoring Framework in Application Server zu integrieren, führen Sie folgende Schritte durch:
    


  1. 

    Bearbeiten Sie die Datei <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml .
    


    Aktualisieren Sie "${InstalledDate}" mit dem Installationsspeicherplatz von Application Server und "${InstalledDate}" mit dem aktuellen Datum.
    



    2. 

  2. 

    Kopieren Sie die Datei <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml  in das Verzeichnis <Install_dir>\appserver\lib.
    



    3. 

  3. 

    Führen Sie den Befehl <MFWK_Install_location>\bin\mfwksetup.bat -r <Install_dir>\appserver\lib\com.sun.cmm.as.xml aus.
    



    4. 



Hinweis – 
Beim Wert "${InstalledLocation}" handelt es sich um den Installationsspeicherort von Application Server c:\Sun\JavaES5\appserver. Beim Wert "$InstalledDate" müssen Sie die Zeit in Millisekunden angeben, indem Sie die aktuelle Zeit in Millisekunden ausgehend von 1970 berechnen.




Beispiele


In diesem Abschnitt werden die bekannten Probleme zum Beispielcode der Application Server 8.2-Software und ihre Lösungen beschrieben.



setup-one-machine-cluster reagiert nicht (Nr. 6195092)


Unter Windows erfordert der Befehl mqfailover, dass Strg+C gedrückt wird, um den nicht mehr reagierenden Prozess abzubrechen. Der Prozess setup-one-machine-cluster  muss erneut ausgeführt werden.


Führen Sie in install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html die folgenden Befehle aus:



Wenn Sie für ein anderes Enterprise Edition-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 andernfallsasant 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


Keine. Dieses Problem beeinträchtigt auf ähnliche Weise alle Enterprise Edition-Beispiele,
die dieses ant-Ziel unter Windows verwenden. Um dieses Problem zu beheben, drücken Sie Strg+ C, um den nicht mehr reagierenden Prozess zu beenden, und führen Sie ihn dann erneut aus.


In der Dokumentation fehlt der ausdrückliche Hinweise, dass JMS-Ressourcen vor der Ausführung von Message Queue Failover Sample Application erstellt werden müssen (Nr. 6198003)


Nach Abschluss der asadmin-Bereitstellungsanweisungen und Ausführen der Message Failover Sample Application wird folgende Fehlermeldung angezeigt:









/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 der manuellen Bereitstellung mit den Befehlen asadmin deploy JMS-Ressourcen manuell erstellt werden müssen. In der Dokumentation wird darüber hinaus nicht erwähnt, dass die vorgegebenen ant-Ziele für das Bereitstellen der Beispielanwendung verwendet werden müssen.


Lösung


Verwenden Sie für das Skript build.xml das Ziel asant deploy. Das Skript erstellt die für die Ausführung der Anwendung erforderlichen JMS-Ressourcen.


Sicherheit


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


Fehler beim Ausführen von WebServiceSecurity-Anwendungen
bei Enterprise Edition mit J2SE 5.0 (Nr. 6183318)



WebServiceSecurity-Anwendungen können aus den folgenden Gründen nicht mit JSE 5.0 ausgeführt werden: 



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.


SSL-Beendigung funktioniert nicht (Nr. 6269102)


Wenn Load Balancer (Hardware) für die SSL-Beendigung konfiguriert ist, ändert Application Server das Protokoll während der Umleitung von https zu http.


Lösung


Fügen Sie zwischen dem Hardware-Lastausgleich und Application Server einen Software-Lastausgleich hinzu.


Aufrüsten


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


Als Beispielskript verwendete Derby-Datenbank wird am falschen Speicherort erstellt (Nr. 6377804)


Dieser Fehler weist zwei Aspekte auf:


    

  1. 

    Wenn die Setup-Skripts der Beispielanwendung, die die Derby-Datenbank verwenden, ausgeführt werden, wird die Derby-Datenbank im aktuellen Verzeichnis oder im Verzeichnis  <install_root>/bin erstellt.
    



    2. 

  2. 

    Das Ant-Beispielskript für build erstellt die Datei  password.txt, mit der die Admin-Passwort-Datei im aktuellen Verzeichnis gespeichert wird. Diese ist jedoch in Nicht-Root-Szenarien und Szenarien mit Sparse-Zones nicht beschreibbar.
    



    3. 



Lösung


    

  1. 

    
Speicherort der Derby-Datenbank – Verwenden Sie die Option  --dbhome mit dem Befehl start-database, um die Datenbank mit dem für --dbhome angegebenen Wert zu erstellen. Die asadmin-Befehlssyntax für  start-database lautet beispielsweise wie folgt:
    


    

    


    

    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false]
[--verbose=false]
    
    		

    

    


    2. 

  2. 

    
Speicherort der Datei password.txt  – Naturgemäß sollte das Beispielverzeichnis beschreibbar sein, da alle Build-Befehle die Erstellungen der Datei password.txt  in diesem Verzeichnis beinhalten. Achten Sie darauf, dass eine Arbeitskopie der Beispiele an einem beschreibbaren Speicherort installiert wird.
    



    3. 



Admin-Benutzername oder Passwort sollte ungültig sein bei Semikolon (;) (Nr. 6473341)


Die Application Server Enterprise Edition
 8.2-Installation lässt keine Sonderzeichen im Namen des Admin-Benutzers zu. Die Domänenerstellung schlägt fehl, wenn Sonderzeichen verwendet werden. Beachten Sie jedoch, dass das Admin-Passwort Sonderzeichen enthalten darf.


Lösung


Vergewissern Sie sich bei der Aufrüstung von Application Server 7 auf Application Server 8.2, dass der Name des Admin-Benutzers keine Sonderzeichen enthält.


Webcontainer


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


Bei Apache und IIS keine Unterstützung für Load Balancer Plugin


Sun Java ES 5 Application Server unterstützt Apache and IIS (Nicht-Sun-Webcontainer) nicht für das Load Balancer-Plugin. Sun Java ES installiert Sun Java System Web Server für die Konfiguration das Load Balancer Plugins.


Bereitstellen einer Anwendung mit --precompilejsp=true  kann zu einer Sperrung von JAR-Dateien führen (Nr. 5004315)


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. Dies liegt daran, 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 ü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. Dieses Szenario 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.


WAR kann nicht mit Servlet 2.4-basierter Datei web.xml, die ein leeres <load-on-startup>-Element enthält, bereitgestellt werden (Nr. 6172006)


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 das Element <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-Datei eine Ganzzahl angegeben werden muss. Wenn eine leere  <load-on-startup> angegeben wurde, wie in <load-on-startup/>, schlägt die Validierung von der Datei web.xml basierend auf dem Servlet 2.4-Schema für die Datei 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.


JSP-Seite kann auf Servern mit geringen Ressourcen nicht kompiliert werden. (Nr. 6184122)


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 hierfür eine der folgenden Vorgehensweisen:



Diese Einstellung verhindert, dass Ant neue Prozesse für die javac-Kompilierung erzeugt.


Application Server unterstützt das Add-On auth-passthrough von Web
Server 6.1 (Nr. 6188932) nicht


Sun Java System Application Server Enterprise Edition
 8.2 fügt Unterstützung für die Funktionalität hinzu, die durch das Plugin auth-passthrough bereitgestellt wird, das in Sun Java System Application Server Enterprise Edition
 7.1 enthalten ist. In Application Server Enterprise Edition
 8.2 ist jedoch die Plugin-Funktion auth-passthrough anders konfiguriert.


Die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition
 7.1 hat sich in zweischichtigen Bereitstellungsszenarien mit folgenden Einschränkungen als nützlich erwiesen: 



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 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 Application Server Enterprise Edition
 8.2 kann die Funktion auth-passthrough aktiviert werden, indem die Eigenschaft authPassthroughEnabled des Elements <http-service> in der Datei domain.xml wie folgt auf
TRUE gesetzt wird:









<property name="authPassthroughEnabled" value="true"/>





Dieselben Sicherheitserwägungen für die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition
 7.1 gelten auch für die Eigenschaft authPassthroughEnabled
 in Application Server Enterprise Edition
 8.2. authPassthroughEnabled ermöglicht das Umgehen von Informationen, die für Authentifizierungszwecke verwendet werden können (wie z. B. die IP-Adresse, von der die Anforderung ausging, oder das SSL-Clientzertifikat). Daher darf nur vertrauenswürdigen Clients oder Servern das Recht gewährt werden, eine Verbindung mit einer Application Server Enterprise Edition
 8.2-Instanz herzustellen, wenn authPassthroughEnabled auf TRUE gesetzt ist. Als Vorsichtsmaßnahme konfigurieren Sie nur Server hinter der firmeneigenen Firewall mit dem auf TRUE gesetzten Befehl authPassthroughEnabled. 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 Plugin service-passthrough konfiguriert wurde und Anforderungen an eine Instanz von Application Server 8.1, Update 2 mit dem auf TRUE gesetzten Befehl authPassthroughEnabled weiterleitet, die SSL-Clientauthentifizierung auf dem Webserver-Proxy aktiviert sowie auf der Proxy-Instanz von Application Server 8.1, Update 2 deaktiviert werden 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.


Bei der Erstellung eines HTTP-Listener mit --enabled=false  ist der Listener nicht deaktiviert (Nr. 6190900)


Wenn ein httplistener mit dem Flag --enabled=false  erstellt wird, wird der Listener dennoch nicht deaktiviert. Das Flag --enabled  bleibt ohne Wirkung, wenn es gleichzeitig mit der Erstellung eines Listeners verwendet wird.


Lösung


Erstellen Sie den Listener im aktivierten Zustand und deaktivieren Sie ihn später manuell.