© Copyright International Business Machines Corporation 2006. Alle Rechte vorbehalten.
© Copyright IBM Deutschland GmbH 2000, 2006. Alle Rechte vorbehalten.
Die Option Auf den Server kopierte Anwendungsdateien minimieren wird von WebSphere® Application Server ab Version 6.0.2.5 unterstützt. Im Servereditor von WebSphere Application Server 6.0 ist ein Markierungsfeld für diese Option; die Option wird ignoriert, wenn Sie für einen Server vor Version 6.0.2.5 ausgewählt wird.
Wenn ein Enterprise JavaBean-Modul (EJB-Modul) von mehreren EAR-Projekten gemeinsam genutzt wird, die auf einem WebSphere Application Server ausgeführt werden, und eines der EAR-Projekte vom Server entfernt wird, müssen die anderen EAR-Projekte erneut gestartet werden, bevor Sie auf Ressourcen wie EJB-Beans im EJB-Projekt zugreifen können.
Wenn Sie diese Aktion nicht durchführen, kann es vorkommen, dass Fehlernachrichten angezeigt werden, die den unten aufgeführten ähneln. Diese Fehler treten auf, weil der JNDI-Name (Java Naming and Directory Interface, JNDI) im EJB-Projekt vom Server entfernt wird, wenn die EAR entfernt wird.
Beispiel für eine Fehlernachricht:
00000028 SystemOut O javax.naming.NameNotFoundException: Context: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: First component in name Session20Home not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
at com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
at ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
at ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
at ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Aufgrund des Verhaltens und verschiedener Interaktionen zwischen den Eclipse- und WebSphere-Laufzeitumgebungen sind zusätzliche Schritte erforderlich, wenn Multithread-WebSphere-Anwendungsclients über das Dialogfenster 'Startkonfigurationen für den Anwendungsclient' ausgeführt werden. Das Dialogfenster 'Startkonfigurationen für den Anwendungsclient' ist in der J2EE-Perspektive verfügbar, wenn Sie Ausführen > Ausführen in der Symbolleiste des Produkts auswählen. Wenn der Client mehrere Threads verwendet oder wenn er Frameworks verwendet, die zusätzliche Threads wie Swing verwenden können, müssen Sie die folgenden zusätzlichen Schritte ausführen:
- Wählen Sie im Dialogfenster 'Startkonfigurationen für den Anwendungsclient' die Registerkarte Argumente aus. Geben Sie im Textfeld VM-Argumente den folgenden Parameter an:
-Dosgi.noShutdown=true- Stellen Sie sicher, dass die Clientanwendung System.exit() aufruft.
Wenn dies nicht angegeben ist, können Probleme auftreten, die sich aus dem Klassenladen oder Java™ Virtual Machines (JVMs) ergeben, die nicht beendet werden, sobald die Anwendung bis zur Fertigstellung ausgeführt wird.
Nehmen Sie an, Sie hätten zum Beispiel ein Anwendungsclientprojekt mit der folgenden Konfiguration:
- für die Projektfacette für Java ist Version 1.4 eingestellt
- für die Zielserverlaufzeit für dieses Projekt ist die Option für sofortige Methodenersetzung in der Serverkonfiguration aktiviert
Es kann vorkommen, dass die Schaltfläche 'Wieder aufnehmen' in der Sicht 'Debug' nicht ordnungsgemäß funktioniert. Wenn Sie die Anwendung auf dem Server zum Beispiel im Debugmodus ausführen, versuchen Sie, die Quelle zur Laufzeit zu ändern, und verwenden anschließend die Schaltfläche 'Wieder aufnehmen', um mit dem Debug der Anwendung fortzufahren. Es kann vorkommen, dass die durch die sofortige Methodenersetzung verursachten Änderungen nicht auf den Quellcode angewendet werden.
Klicken Sie zwei Mal auf die Schaltfläche 'Wieder aufnehmen', damit die Laufzeitänderungen wirksam werden.
Hinweis: Dieses Problem tritt nicht auf, wenn Sie für die Projektfacette für Java Version 5.0 einstellen.
Die Schaltfläche Entfernen im Dialogfenster 'Gemeinsame WebSphere-Server verwalten' funktioniert nicht ordnungsgemäß.
Tipp: Gehen Sie wie folgt vor, um das Dialogfenster 'Gemeinsame WebSphere-Server verwalten' zu öffnen:
- Wählen Sie in der Symbolleiste Fenster > Benutzervorgaben aus. Das Dialogfenster 'Benutzervorgaben' wird geöffnet.
- Wählen Sie im linken Teilfenster Server > WebSphere > WebSphere 5.1 aus.
- Klicken Sie im rechten Teilfenster neben dem Feld 'Gemeinsame WebSphere-Server' auf die Schaltfläche Verwalten. Das Dialogfenster 'Gemeinsame WebSphere-Server verwalten' wird geöffnet.
Wenn Sie die Schaltfläche 'Entfernen' verwenden, wird angezeigt, der Server sei entfernt. Wenn Sie das Dialogfenster jedoch schließen, wieder öffnen und die Informationen zu den fernen Servern aktualisieren, wird der vorher entfernte Server wieder im Dialogfenster angezeigt.
Zur Umgehung dieses Problems können Sie den Eintrag für gemeinsam genutzte Server manuell entfernen. Führen Sie hierzu die folgenden Schritte aus:
- Öffnen Sie die Datei id.txt, die sich im folgenden Verzeichnis befindet:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
Hierbei steht <directory> für das Installationsverzeichnis von Agent Controller.- Löschen Sie den Eintrag, der auf den gemeinsam genutzten Server verweist, den Sie entfernen möchten.
- Entfernen Sie das WebSphere-Implementierungsverzeichnis, das für diesen konkreten gemeinsam genutzten Server während der Servererstellung angegeben wurde mit allen seinen Unterverzeichnissen. Im WebSphere-Implementierungsverzeichnis müssen zum Beispiel die folgenden Unterverzeichnisse entfernt werden: 'config', 'installedApps', 'temp' und alle anderen Verzeichnisse und Dateien, die sich in diesem Verzeichnis befinden.
- Geben Sie im Dialogfenster 'Gemeinsame WebSphere-Server verwalten' einen Hostnamen an, und klicken Sie auf die Schaltfläche Aktualisieren, um sicherzustellen, dass Sie den gemeinsam genutzten Server erfolgreich entfernt haben.
Wenn Sie über weitere Server wie zum Beispiel einen IBM HTTP Server verfügen, die in demselben WebSphere Application Server 6.x-Profil installiert sind, kann es vorkommen, dass auf der Seite 'Einstellungen für den WebSphere-Server' des Assistenten 'Neuer Server' nicht die korrekten RMI-Portnummern (Remote Method Invocation, RMI) oder SOAP-Portnummern lokalisiert werden. Außerdem kann es vorkommen, dass die Portnummer für die Verwaltungskonsole nicht abgerufen wird.
Wenn der Assistent 'Neuer Server' nicht die für einen Server definierten Portnummern lokalisieren kann, werden die Portfelder vorläufig standardmäßig mit den Standardportnummern gefüllt: 2809 für RMI und 8880 für SOAP.
Wenn falsche Portnummern definiert werden, können die folgenden Probleme auftreten:
- Eine Verbindung zum neuen Server kann nicht aufgebaut werden, der Server kann zum Beispiel nicht gestartet der gestoppt werden.
- Die Verwaltungskonsole kann nicht von diesem neuen Server aus geöffnet werden; es kann eine Fehlernachricht angezeigt werden, die besagt, dass der Port der Verwaltungskonsole nicht definiert ist.
- Auf diesem Server können keine Anwendungen ausgeführt werden, da der Befehl 'Auf Server ausführen' nicht funktioniert.
Problemumgehung:
- Geben Sie die Portwerte eines konfigurierten Profils an, indem Sie auf seine Serverkonfigurationsdateien verweisen. Die Portwerte werden in der Datei 'serverindex.xml' gespeichert, die sich im folgenden Verzeichnis befindet:
<directory>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>; dabei steht <directory> für das Installationsverzeichnis von WebSphere Application Server.
Verwenden Sie die Datei 'serverindex.xml' zum Füllen der folgenden Tabelle, um die tatsächlichen Portnummern anzugeben, die für den Server definiert sind:
Portname Portbeschreibung Standard portnummer Ihre zugeordnete Portnummer SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Verwaltungskonsole 9060 WC_defaulthost HTTP-Transport 9080 - Um eine Verbindung zum Server aufzubauen, geben Sie die korrekte RMI- oder SOAP-Portnummer an, wenn Sie den Server erstellen.
- Verwenden Sie zum Starten der Verwaltungskonsole einen externen Web-Browser, und geben Sie im Adressfeld die URL zum korrekten Port der Verwaltungskonsole ein:
http://<machine_name>:<WC_adminhost>/IBM/console
Beispiel: http://localhost:9060/IBM/console- Zum Ausführen von Anwendungen auf dem Server setzen Sie den Befehl 'Auf Server ausführen' ab. Wenn der Web-Browser geöffnet wird, korrigieren Sie die URL mit der Portnummer für den HTTP-Transport, die für den Server definiert ist.
http://<machine_name>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
Beispiel: http://localhost:9080/MyApplication/index.jsp
Hinweis: Es kann vorkommen, dass die automatisch definierten Server in der Sicht 'Server' nicht auf die richtigen Portnummern zum tatsächlichen Server verweisen. Wenn dies der Fall ist, verwenden Sie die oben beschriebene Problemumgehung.
Das Tool für die Profilverwaltung ist ein WebSphere Application Server-Tool, das ein Profil für jede Laufzeitumgebung erstellt. Sie können das Profilverwaltungstool von WebSphere Application Server über die Workbench starten. Das Tool für die Profilverwaltung funktioniert jedoch nicht unter einem 64-Bit-Prozessor. Verwenden Sie stattdessen das Befehlszeilentool manageprofiles, das von WebSphere Application Server bereitgestellt wird.
Wenn Sie unter Windows-Betriebssystemen den Port für den Methodenaufruf über Remotezugriff (Remote Method Invocation, RMI) für Verbindungen zu WebSphere Application Server 6.x verwenden, kann es vorkommen, dass beim Aufbauen einer Verbindung zum Server nach dem Verlust der Netzkonnektivität lange Verzögerungen auftreten. Dies kann sogar der Fall sein, wenn es sich um einen lokalen Server handelt und der Verlust der Netzkonnektivität nur vorübergehend auftrat, was in einem mobilen Netz häufig vorkommt.
Wenn Sie wissen, dass der Server gestartet ist, in den Sichten 'Server' jedoch der Status Gestoppt oder Wird gestartet angezeigt wird, versuchen Sie, eine Verbindung zum Server durch einen Wechsel der Serververbindung von RMI zu SOAP aufzubauen. Als Status des Servers müsste dann Gestartet angezeigt werden.Beim Aufbau einer Verbindung zu einem Server in einem mobilen Netz stehen Ihnen eine Reihe von Optionen zur Verfügung:
- Die einfachste und sicherste Lösung ist die Verwendung des SOAP-Ports für die Verbindung. Nach dem Verlust der Netzkonnektivität verläuft die Wiederherstellung von SOAP-Verbindungen schneller als die von RMI-Verbindungen.
- Wenn Sie eine RMI-Verbindung verwenden müssen, können Sie versuchen, die Standardeinstellungen zu verändern, die das DNS-Caching (Domain Name System, DNS) in einem Windows-Betriebssystem betreffen. Einzelheiten hierzu finden Sie im folgenden Artikel der Microsoft-Unterstützung:
http://support.microsoft.com/kb/318803
Windows-Betriebssystems verfügen über ein integriertes DNS-Caching, das aufgelöste Hostnamen verwaltet. Dies ermöglicht eine höhere Geschwindigkeit bei der DNS-Suche. Der Nachteil dieser Methode ist jedoch das Verhalten beim Fehlschlagen einer DNS-Suche. Das Windows-Betriebssystem zwischenspeichert den fehlgeschlagenen Wert standardmäßig für einen Zeitraum von 300 Sekunden. Auch wenn der DNS-Server kurz danach die Suche erfolgreich auflösen könnte, versucht er dies nicht, bis die Zeitdauer für den Cache abgelaufen ist. Aus diesem Grund kann eine fehlgeschlagene DNS-Suche bei Verwendung der Standardeinstellungen bis zu 5 Minuten dauern, bevor eine echte Wiederholung der Suche versucht wird. Wenn Sie als Zeitdauer für das Zwischenspeichern 0 Sekunden einstellen, wird das Windows-Betriebssystem zwangsläufig nie fehlgeschlagene DNS-Suchabfragen zwischenspeichern. Eine Neuverbindung wird dann hergestellt, wenn das DNS verfügbar wird.
Im folgenden Beispiel wird beschrieben, wie das DNS-Caching für fehlgeschlagene Suchen in Windows-Betriebssystemen inaktiviert wird:
Fügen Sie zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
einen der folgenden Registerwerte hinzu:
- Für Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Für Windows 2000:
"NegativeCacheTime"=dword:00000000
Für die Anwendung einer Vielzahl an Ressourcenänderungen, die auf der Seite 'Implementierung' des Editors für den Implementierungsdeskriptor der Anwendung auf dem Server definiert wurden, sind eine erneute Veröffentlichung, ein Neustart der Anwendung oder ein Deinstallieren und Neuinstallieren der Anwendung keine ausreichenden Aktionen. Von der Änderung des Datenbanknamens einer Datenquelle auf der Seite 'Implementierung' des Editors ist bekannt, dass sie nicht vom Server berücksichtigt werden kann, es ist jedoch möglich, dass der Server auch einige andere Änderungen nicht berücksichtigen kann.
Führen Sie zur Umgehung des Problems die folgenden Schritte aus, um die Änderungen auf dem Server anzuwenden:
- Stoppen Sie den Server.
- Klicken Sie in der Sicht 'Server' mit der rechten Maustaste auf den Server, und wählen Sie Stoppen aus.
- Warten Sie in der Sicht 'Server', bis als Status des Servers Gestoppt angezeigt wird, und fahren Sie anschließend mit dem nächsten Schritt fort.
- Starten Sie die Workbench.
Hinweis: Wenn der Start des Servers fehlschlägt, müssen Sie die Funktionen des Betriebssystems zum Stoppen des Java-Prozesses verwenden, auf dessen Grundlage der Server ausgeführt wird. Alternativ können Sie die Workbench erneut starten und anschließend versuchen, den Server wieder zu starten.- Starten Sie den Server.
- Klicken Sie in der Sicht 'Server' mit der rechten Maustaste auf den Server, und wählen Sie Starten aus.
- Warten Sie in der Sicht 'Server', bis die Publizierung abgeschlossen ist und als Status des Servers Gestartet angezeigt wird, und fahren Sie anschließend mit dem nächsten Schritt fort.
- Führen Sie die Anwendung auf dem Server aus. Verwenden Sie dazu zum Beispiel den Befehl Auf Server ausführen. Daraufhin müsste der Server in der Lage sein, die Änderungen vom Editor für den Implementierungsdeskriptor der Anwendung zu berücksichtigen.
Wenn Sie eine Dienstprogramm-JAR-Datei zu Webbibliotheken für ein Webprojekt hinzufügen und auf Klassen in der JAR-Datei im Code verweisen, kann der Fehler java.lang.NoClassDefFoundError angezeigt werden, wenn Sie versuchen, die Anwendung auf dem Server auszuführen.
Als Problemumgehung fügen Sie nach dem Hinzufügen einer Dienstprogramm-JAR-Datei zum EAR-Modul die JAR-Datei zu den J2EE-Modulabhängigkeiten des Webprojekts hinzu. Führen Sie dazu die folgenden Schritte aus:
- Fügen Sie eine Dienstprogramm-JAR-Datei zum EAR-Modul hinzu. Einzelheiten hierzu finden Sie in der Produkthilfe im Thema JAR-Dateien für Projektdienstprogramme hinzufügen.
- Klicken Sie mit der rechten Maustaste auf das Webprojekt, und wählen Sie Eigenschaften aus. Das Dialogfenster 'Eigenschaften' wird geöffnet.
- Wählen Sie J2EE-Modulabhängigkeiten aus.
- Wählen Sie in der Registerkarte J2EE-Module unterhalb der Spalte JAR/Modul das Markierungsfeld neben der Dienstprogramm-JAR-Datei aus.
Wenn WebSphere Application Server 6.1 mit einer gesicherten SOAP-Verbindung ausgeführt wird, schlägt eine weitere gesicherte SOAP-Verbindung zu WebSphere Application Server 6.0 fehl. Dasselbe Problem tritt auch in umgekehrter Reihenfolge auf: wenn WebSphere Application Server 6.0 mit einer gesicherten SOAP-Verbindung ausgeführt, hat dies zur Folge, dass eine weitere gesicherte Verbindung zu WebSphere Application Server 6.1 fehlschlägt. Das Problem tritt jedoch nicht auf, wenn der Server in der Sicht 'Server' definiert ist und keine Statusangabe für den Server angezeigt wird.
Zur Umgehung des Problems verwenden Sie eine gesicherte RMI-Verbindung (Remote Method Invocation, RMI) anstatt einer SOAP-Verbindung oder eine nicht gesicherte SOAP-Verbindung.
Wenn der ferne Server gestoppt wird, kann es lange dauern, bis der Assistent 'Neuer Server' beendet wird, nachdem Sie auf die Schaltfläche Fertig stellen klicken. Zur Problemumgehung starten Sie den fernen Server, bevor Sie auf die Schaltfläche Fertig stellen im Assistenten 'Neuer Server' klicken.
Wenn sich eine Datei mit der Erweiterung .war im Ordner 'EarContent' eines Projekts befindet und nicht als Webmodul in der Datei 'application.xml' definiert ist, schlägt die Publizierung der Unternehmensanwendung auf dem Server mit folgender Fehlernachricht fehl:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Das verschachtelte Archiv "abc.war" konnte nicht in "D:\myworkspace\PublishEAR\EarContent" geöffnet werden.Dieser Fehler tritt auf, weil die Datei von der Workbench nicht ordnungsgemäß als Webmodul gehandhabt werden kann. Wählen Sie eine der folgenden Strategien zur Behebung des Problems aus:
- Wenn die Datei ein Webmodul ist, fügen Sie die Datei als Modul zur Unternehmensanwendung hinzu. Einzelheiten hierzu finden Sie in der Produkthilfe unter dem Thema Einer Unternehmensanwendung Module hinzufügen.
- Wenn die Datei kein Webmodul ist, wäre eine Möglichkeit zur Umgehung des Publizierungsproblems eine Änderung der Dateierweiterung in eine andere Dateierweiterung als .war, zum Beispiel in .jar.
Wenn Sie das Implementierungsverzeichnis und das Publizierungsverzeichnis eines fernen WebSphere Application Server 5.1 oder eines fernen WebSphere Application Server 5.1 Express im Servereditor ändern und anschließend die Anwendung erneut publizieren, wird die Anwendung weiterhin an der vorherigen Position publiziert. Somit werden Ihre Änderungen am Publizierungs- und am Implementierungsverzeichnis nicht angewendet. Dieses Problem tritt auf, wenn entweder lokale Kopiermethoden oder FTP-Methoden verwendet werden.
Starten Sie zur Umgehung des Problems die Workbench erneut. Danach müssten die Konfigurationsänderungen für das Publizierungsverzeichnis und das Implementierungsverzeichnis wirksam geworden sein.
Zur Unterstützung eines flexibleren Ansatzes zur Speicherung von Projekten wurde das Verfahren zur Publizierung von Anwendungen geändert. Anwendungen werden jetzt kopiert, bevor sie auf dem Server publiziert werden. Wenn die Anwendung umfangreich ist, also zum Beispiel größer als 100 Megabyte, nimmt diese Kopieroperation für den Publizierungsbefehl mehr Zeit in Anspruch, als hierfür in vorherigen Versionen erforderlich war.
Hierzu gibt es derzeit keine Problemumgehung. IBM® arbeitet an einer Aktualisierung, die die Ausführung dieser neuen Kopieroperation für die meisten Klassen überflüssig macht.
Wenn ein sicherer WebSphere Application Server 6.1 gestartet ist und Sie im Servereditor den Serververbindungstyp entweder in RMI (Remote Method Invocation) oder SOAP (Simple Object Access Protocol) ändern, kann es vorkommen, dass nach dem Speichern der Änderungen im Servereditor eine Fehlernachricht angezeigt wird, die besagt, dass die Publizierung fehlgeschlagen ist:
Es wird keine Publizierung ausgeführt, da der Server nicht gestartet wurde. Starten Sie den Server, bevor Sie die Publizierungsoperation ausführen.
Sie können diese Fehlernachricht einfach ignorieren. Optional können Sie nach dem Wechsel des Serverstatus in der Sicht 'Server' in den Status Gestartet einen Publizierungsbefehl ausgeben (klicken Sie in der Sicht 'Server' mit der rechten Maustaste auf den Server, und wählen Sie Publizieren aus).
Wenn Sie versuchen, mit Hilfe des Assistenten 'Ersteller für Tabellen und Datenquellen' eine Datenquelle zu generieren, kann der Fehler TargetInvocationException im Abschnitt 'Details' des Dialogfensters 'Ergebnisse der Tabellen- und Datenquellenerstellung' auftreten.
Ursache für den Fehler 'TargetInvocationException' könnte der Import eines Projektdatenaustauschs sein, in dem Datenquellen enthalten sind, die mit demselben JNDI-Namen (Java Naming and Directory Interface, JNDI) definiert wurden.
Zur Vermeidung des Fehlers 'TargetInvocationException' überprüfen Sie, ob bereits eine Datenquelle mit demselben JNDI-Namen in der Workbench definiert ist. Falls dies der Fall ist, entfernen Sie sie auf der Seite 'Implementierung' des 'Editors für den Implementierungsdeskriptor der Anwendung', und erstellen die Datenquelle anschließend unter Verwendung eines anderen JNDI-Namens erneut. Der JNDI-Name muss eindeutig sein, da der Benennungs- und Suchservice zum Binden einer Enterprise-Bean an eine Datenquelle verwendet wird.
Wenn der Server in der Sicht 'Server' gestoppt wird, kann es vorkommen, dass der Server nicht vollständig gestoppt wird. In der Sicht 'Server' wird zwar Gestoppt angezeigt, der Serverprozess kann sich aber in einem Zustand befinden, in dem der Server nicht antwortet. Dies tritt in der Regel auf, wenn Artefakte wie Ihre Anwendung oder die Workbench weiterhin Verweise auf Klassen auf dem Server beibehalten. Im Folgenden werden Beispielszenarios beschrieben:
- Anwendungen, die sich in einer Endlosschleife befinden oder Anwendungen, die weiterhin Verweise auf Klassen auf dem Server beibehalten
- Anwendungen, die eine Verbindung zu einer Cloudscape- oder Derby-Datenbank herstellen, ohne ihre Verbindung vorher zu bereinigen
- Verwendung der Schaltfläche Verbindung testen im Assistenten 'Neue Verbindung' der Datentools zum Herstellen einer Verbindung zu einer Cloudscape- oder Derby-Datenbank ohne Trennung der Verbindung zur Datenbank
Einschränkung: Mehrere Verbindungen zu einer einzelnen Cloudscape- oder Derby-Datenbank werden aufgrund einer Konfigurationseinschränkung nicht unterstützt. Wenn Sie die Datenbankverbindung zur Datenbank vom Datenbankexplorer aufrecht erhalten und ein Server versucht, eine weitere Verbindung zu einer Cloudscape- oder Derby-Datenbank über eine Datenquelle herzustellen, schlägt die zweite Verbindung fehl. Somit müssen Sie die Verbindung vom Datenbankexplorer schließen, bevor ein Server eine Verbindung zu einer Cloudscape- oder Derby-Datenbank aufbauen kann.
Problemumgehung: Stoppen Sie unter Verwendung der Funktionen des Betriebssystems den Java-Prozess, auf dessen Grundlage der Server ausgeführt wird. Alternativ können Sie die Workbench erneut starten, um zu erzwingen, dass der Verweis aufgelöst wird. Im letzten Beispielszenario, das im dritten Listenpunkt beschrieben wird, können Sie in der Sicht 'Datenbankexplorer' eine Verbindung zur Cloudscape- oder Derby-Datenbank herstellen und anschließend diese Verbindung trennen.
Wenn Sie Ressourcen wie zum Beispiel eine Enterprise-Bean auf dem Server publizieren, und zum Testen einer EJB den universellen Testclient (Universal Test Client, UTC) verwenden, kann es vorkommen, dass die JAR-Datei blockiert wird und nicht aktualisiert werden kann. Dies hat zur Folge, dass Änderungen, die an den Tools während des Testens der EJB vorgenommen wurden, nicht berücksichtigt werden. Sobald die EJB-JAR-Datei vom UTC geladen wird, bleibt die JAR-Datei blockiert, bis die Anwendung entfernt und erneut hinzugefügt wird oder der Server neu gestartet wird.
Problemumgehung: Verwenden Sie den UTC in einer Entwicklungsumgebung, in der für die Ressourcen der Anwendung eine Knappheit an Arbeitsbereich herrscht und in der sie nicht auf dem Server ausgeführt werden. Dies können Sie mit Hilfe des Assistenten 'Neuer Server' konfigurieren oder später mit Hilfe des Servereditors ändern, indem Sie die Option Server mit Ressourcen im Arbeitsbereich ausführen aus den Optionen für die Publizierung auswählen. So können einzelne Dateien in dem EJB-Projekt aktualisiert werden, ohne dass eine vollständige Ersetzung der gesamten EJB-JAR-Datei erforderlich wird.
Nach dem vollständigen Testen der Anwendung kann diese auf dem Server mit der Publizierungsoption Server mit Ressourcen auf dem Server ausführen publiziert werden.