© Copyright International Business Machines Corporation 2006. All rights reserved.
© Copyright IBM Deutschland GmbH 2006. Alle Rechte vorbehalten.
Die Option Auf den Server kopierte Anwendungsdateien minimieren wird von WebSphere® Application Server 6.0.2.5 und später unterstützt. Im Servereditor von WebSphere Application Server Version 6.0 ist eine Markierungsfeld für die Option vorhanden. Die Option wird ignoriert, wenn sie für Server vor Version 6.0.2.5 ausgewählt wird.
Wenn ein Enterprise JavaBean-Modul (EJB-Modul) zwischen mehreren EAR-Projekten, die auf WebSphere Application Server ausgeführt werden, gemeinsam genutzt wird, und es wird eines der EAR-Projekte vom Server entfernt, dann müssen die übrigen EAR-Projekte neu gestartet werden, um auf die Ressourcen (wie zum Beispiel EJB-Beans) in dem EJB-Projekt zugreifen zu können.
Wenn Sie diese Aktion nicht durchführen, werden möglicherweise Fehlernachrichten der Art wie unten aufgeführt angezeigt. Diese Fehler treten auf, weil der JNDI-Name (JNDI: Java Naming and Directory Interface) in einem EJB-Projekt vom Server entfernt wird, wenn die EAR entfernt wird.
Der folgende Absatz enthält eine Beispielfehlernachricht:
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)
Bedingt durch diverse Verhaltensweisen und Interaktionen zwischen den Laufzeitumgebungen von Eclipse und von WebSphere sind zusätzliche Schritte erforderlich, wenn Sie Multithread-WebSphere-Anwendungsclients über das Dialogfenster für Startkonfigurationen für Anwendungsclients ausführen. Sie finden das Dialogfenster für Startkonfigurationen für Anwendungsclients in der J2EE-Perspektive, wenn Sie in der Symbolleiste des Produkts Ausführen > Ausführen... auswählen. Wenn Ihr Client mehrere Threads verwendet oder Frameworks nutzt, die zusätzliche Threads wie beispielsweise Swing benutzen können, müssen Sie die folgenden zusätzlichen Schritte ausführen:
- Wählen Sie im Dialogfenster für Startkonfigurationen für Anwendungsclients die Registerkarte Argumente aus. Geben Sie unter dem Textfeld VM-Argumente folgenden Parameter an:
-Dosgi.noShutdown=true- Stellen Sie sicher, dass Ihre Clientanwendung System.exit() aufruft.
Wenn Sie diese Angaben nicht machen, könnten Probleme beim Laden von Klassen auftreten oder mit virtuellen Java™-Maschinen (JVMs), die nach Beendigung der Anwendung nicht geschlossen und verlassen werden.
Angenommen, Ihr Anwendungsclientprojekt ist wie folgt konfiguriert:
- für die Projektfacette für Java ist Version 1.4 angegeben
- bei der Zielserverlaufzeit für dieses Projekt ist in der Serverkonfiguration die Option für die sofortige Methodenersetzung aktiviert
Möglicherweise stellen Sie fest, dass die Schaltfläche 'Wieder aufnehmen' in der Debugsicht nicht korrekt funktioniert. Sie führen zum Beispiel die Anwendung auf dem Server in Debugmodus aus, versuchen dann, die Quelle während der Laufzeit zu ändern, und verwenden anschließend die Schaltfläche 'Wieder aufnehmen', um das Debugging für die Anwendung fortzusetzen. Eventuell werden die Änderungen der sofortigen Methodenersetzung am Quellcode nicht übernommen.
Klicken Sie zwei Mal auf die Schaltfläche 'Wieder aufnehmen', damit die Laufzeitänderungen in Kraft treten können.
Hinweis: Dieses Problem tritt nicht auf, wenn Sie für die Projektfacette für Java Version 5.0 angeben.
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 v51 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' benutzen, scheint es, als ob der Server entfernt worden wäre. Wenn Sie jedoch das Dialogfenster verlassen und anschließend wieder öffnen, und dann die Informationen für den fernen Server aktualisiert anzeigen, wird der zuvor entfernte Server immer noch im Dialogfenster angezeigt.
Zur Umgehung dieses Problems können Sie durch Ausführen der folgenden Schritte den Eintrag für den gemeinsam genutzten Server manuell entfernen.
- Öffnen Sie die Datei id.txt. Diese Datei befindet sich in folgendem Verzeichnis:
<verzeichnis>/plugins/com.ibm.etools.websphere.tools*/properties
Hierbei gibt <verzeichnis> das Installationsverzeichnis von Agent Controller an.- Löschen Sie den Eintrag, der sich auf den zu entfernenden gemeinsam genutzten Server bezieht.
- Entfernen Sie das WebSphere-Implementierungsverzeichnis, das bei der Servererstellung für diesen gemeinsam genutzten Server angegeben wurde, und löschen sie auch alle enthaltenen Unterverzeichnisse. Folgende Verzeichnisse sind beispielsweise Unterverzeichnisse, die im WebSphere-Implementierungsverzeichnis enthalten sind und entfernt werden müssen: config, installedApps, temp. Entfernen Sie außerdem alle weiteren 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 zu prüfen, ob der gemeinsam genutzte Server tatsächlich erfolgreich entfernt wurde.
Wenn zusätzliche Server vorhanden sind, beispielsweise IBM HTTP Server, und diese Server innerhalb des gleichen Profils für WebSphere Application Server Version 6.x installiert sind, werden auf der Seite 'Einstellungen für den WebSphere-Server' im Assistenten 'Neuer Server' eventuell nicht der korrekte Methodenaufruf über Remotezugriff (RMI: Remote Method Invocation) oder die korrekten SOAP-Portnummern gefunden. Zusätzlich wird unter Umständen die Portnummer für die Administrationskonsole nicht abgerufen.
Wenn der Assistent 'Neuer Server' nicht die tatsächlichen Portnummern finden kann, die für einen Server definiert wurden, werden in den Feldern für die Portnummern im Rahmen des Standardverhaltens des Assistenten die Standardportnummern 2809 für RMI und 8880 für SOAP eingefügt.
In dem Fall, dass falsche Portnummern definiert sind, können folgende Probleme auftreten:
- Es kann keine Verbindung zu dem neuen Server hergestellt werden, was bedeutet, dass der Server nicht gestartet bzw. nicht gestoppt werden kann.
- Von dem neuen Server aus kann die Administrationskonsole nicht geöffnet werden. Demzufolge wird möglicherweise ein Fehler des Typs 'Port für Administrationskonsole nicht definiert' gemeldet.
- Auf diesem Server können keine Anwendungen ausgeführt werden, da der Befehl 'Auf Server ausführen' nicht funktioniert.
Problemumgehung:
- Ermitteln Sie die Portwerte für ein konfiguriertes Profil, indem Sie dessen Serverkonfigurationsdateien prüfen. Die Portwerte sind in der Datei 'serverindex.xml' in folgendem Verzeichnis gespeichert:
<verzeichnis>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName> Hierbei gibt <verzeichnis> das Installationsverzeichnis von WebSphere Application Server an.
Orientieren Sie sich an dem Inhalt der Datei 'serverindex.xml', um die Tabelle unten auszufüllen und so die Portnummern zu ermitteln, die tatsächlich für Ihren Server definiert sind:
Portname Portbeschreibung Standardportnummer Ihre zugewiesene Portnummer SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Administrationskonsole 9060 WC_defaulthost HTTP-Transport 9080 - Um eine Verbindung zum Server herzustellen, geben Sie die korrekte RMI-Portnummer bzw. SOAP-Portnummer bei der Erstellung des Servers an.
- Verwenden Sie zum Starten der Administrationskonsole einen externen Web-Browser, und geben Sie im Adressfeld die URL zu dem korrekten Port der Administrationskonsole an:
http://<name_der_maschine>:<WC_adminhost>/IBM/console
Beispiel: http://localhost:9060/IBM/console- Wenn Sie Anwendungen auf dem Server ausführen möchten, setzen Sie einen Befehl 'Auf Server ausführen' ab. Wenn der Web-Browser geöffnet wird, korrigieren Sie die URL-Adresse mit der für Ihren Server definierten Portnummer für HTTP-Transport.
http://<name_der_maschine>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
Beispiel: http://localhost:9080/MyApplication/index.jsp
Hinweis: Die automatisch definierten Server in der Sicht 'Server' verweisen möglicherweise nicht mit den korrekten Portnummern auf den aktuellen Server. Verwenden Sie in diesem Fall das gleiche Verfahren zur Problemumgehung.
Das Profilverwaltungstool ist ein Tool von WebSphere Application Server, das das Profil für jede Laufzeitumgebung erstellt. Das Profilverwaltungstool von WebSphere Application Server kann von der Workbench aus gestartet werden. Das Tool für die Profilverwaltung funktioniert jedoch nicht unter 64-Bit-Prozessoren. Verwenden Sie statt dessen das Befehlszeilentool manageprofiles von WebSphere Application Server.
Bei Windows-Betriebssystemen treten möglicherweise lange Verzögerung bei der Herstellung einer Verbindung zum Server nach Verlust der Netzkonnektivität auf, wenn Sie den RMI-Port für den Methodenaufruf über Remotezugriff zum Herstellen der Verbindung zu WebSphere Application Server Version 6.x verwenden. Dies kann auch eintreten, selbst wenn es sich um einen lokalen Server handelt und die Netzkonnektivität nur vorübergehend nicht mehr gegeben ist, was in einer festnetzunabhängigen Netzumgebung häufig auftritt.
Wenn Sie sicher sind, dass der Server gestartet wurde, in der Serversicht jedoch der Status Gestoppt oder Wird gestartet angezeigt wird, versuchen Sie, ob Sie eine Verbindung zum Server herstellen können, indem Sie die Serververbindung von RMI zu SOAP wechseln. Als Serverstatus sollte nun Gestartet angezeigt werden.Es gibt einige Optionen zum Einrichten einer Verbindung zu einem Server in einer netzunabhängigen Netzumgebung:
- Die schnellste und einfachste Option besteht darin, die Verbindung so zu konfigurieren, dass der SOAP-Port verwendet wird. Nach einem Verlust der Netzkonnektivität werden SOAP-Verbindungen im Vergleich zu RMI-Verbindungen zügiger wieder hergestellt.
- Wenn Sie unbedingt eine RMI-Verbindung benötigen, sollten Sie versuchen, die Standardeinstellungen für das DNS-Caching auf dem Windows-Betriebssystem zu ändern. Genauere Informationen hierzu enthält der folgende Artikel vom Microsoft Support:
http://support.microsoft.com/kb/318803
Das Das Windows-Betriebssystem ist mit integriertem DNS-Caching ausgestattet, das aufgelöste Hostnamen beibehält. Dies ermöglicht einen beschleunigten Durchsatz bei der Ausgabe von DNS-Suchen. Der Nachteil hierbei macht sich bemerkbar, wenn eine DNS-Suche fehlschlägt. Das Windows-Betriebssystem speichert den fehlgeschlagenen Wert standardmäßig 300 Sekunden lang im Cache. Selbst wenn der DNS-Server den DNS-Namen schon wenig später auflösen kann, erfolgt die eigentliche Suche erst, wenn die Gültigkeitsdauer im Cache abgelaufen ist. Demzufolge kann eine fehlgeschlagene DNS-Suche mit Standardeinstellungen bis zu 5 Minuten in Anspruch nehmen, bevor eine echte Wiederholung der Suchanfrage erfolgt. Die Angabe von 0 Sekunden als Gültigkeitsdauer für den Cache erzwingt, dass das Windows-Betriebssystem fehlgeschlagene DNS-Suchabfragen nie im Cache ablegt und ermöglicht so, dass eine Wiederherstellung der Verbindung erfolgen kann, sobald das DNS verfügbar ist.
Der folgende Abschnitt veranschaulicht in Form eines Beispiels, wie Sie das DNS-Caching für fehlgeschlagene Suchen auf Windows-Betriebssystemen inaktivieren:
Fügen Sie in dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
einen der folgenden Registrierungswerte hinzu:
- Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Windows 2000:
"NegativeCacheTime"=dword:00000000
Eine Reihe von Ressourcenänderungen, die auf der Seite 'Implementierung' im 'Editor für Implementierungsdeskriptor der Anwendung' vorgenommen wurden, können auf dem Server nicht umgesetzt werden, auch nicht durch erneutes Publizieren einer Anwendung, erneutes Starten der Anwendung oder das Deinstallieren und anschließende Neuinstallieren der Anwendung. Es ist bekannt, dass es sich bei der Änderung eines Datenbanknamens für eine Datenquelle auf der Editorseite 'Implementierung' um eine Aktion handelt, die der Server nicht berücksichten kann; unter Umständen gibt es jedoch noch weitere Änderungen, die der Server ebensowenig umsetzen kann.
Zur Umgehung des Problems sollten Sie die folgenden Schritte ausführen und so sicherstellen, dass die Änderungen auf dem Server angewendet werden.
- Stoppen Sie den Server.
- Klicken Sie in der Sicht 'Server' auf die rechte Maustaste, und wählen Sie Stoppen aus.
- Warten Sie, bis in der Sicht 'Server' der Status Gestoppt für den Server angezeigt wird, und fahren Sie dann mit dem nächsten Schritt fort.
- Starten Sie die Workbench.
HINWEIS: Falls der Serverstart fehlschlägt, müssen Sie die Funktionen Ihres Betriebssystems nutzen und auf diese Weise den java-Prozess anhalten, auf dem der Server ausgeführt wird. Alternativ hierzu können Sie die Workbench neu starten und dann versuchen, den Server wieder zu starten.- Starten Sie den Server.
- Klicken Sie in der Sicht 'Server' auf die rechte Maustaste, und wählen Sie Starten aus.
- Warten Sie in der Sicht 'Server', bis die erneute Publizierung abgeschlossen worden ist und der Status Gestartet für den Server und die Anwendung angezeigt wird, und fahren Sie dann mit dem nächsten Schritt fort.
- Führen Sie die gewünschte Anwendung auf dem Server aus. Verwenden Sie hierzu zum Beispiel den Befehl Auf Server ausführen. Demzufolge müsste der Server jetzt in der Lage sein, die Änderungen aus dem 'Editor für Implementierungsdeskriptor der Anwendung' zu berücksichtigen.
Wenn Sie eine Dienstprogramm-JAR-Datei für ein Webprojekt zu Webbibliotheken hinzufügen und auf Klassen innerhalb der JAR-Datei in Ihrem Code verweisen, wird möglicherweise ein Fehler java.lang.NoClassDefFoundError gemeldet, wenn Sie versuchen, die Anwendung auf dem Server auszuführen.
Zur Umgehung des Problems sollten Sie, nachdem Sie eine Dienstprogramm-JAR-Datei zu dem EAR-Modul hinzugefügt haben, die JAR-Datei zu den J2EE-Modulabhängigkeiten des Webprojekts hinzufügen. Führen Sie hierzu die folgenden Schritte aus:
- Fügen Sie eine Dienstprogramm-JAR-Datei zu dem EAR-Modul hinzu. Nähere Informationen hierzu enthält das Thema Adding project utility JAR files in der Produkthilfe.
- 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 auf der Registerkarte J2EE-Module unter der Spalte JAR/Modul das Markierungsfeld neben Ihrer Dienstprogramm-JAR-Datei aus.
Wenn WebSphere Application Server Version 6.1 auf einer gesicherten SOAP-Verbindung ausgeführt wird, schlägt eine andere sichere SOAP-Verbindung zu einem WebSphere Application Server Version 6.0 fehl. Das gleiche Problem tritt in umgekehrter Richtung auf: Die Ausführung von WebSphere Application Server Version 6.0 auf einer gesicherten SOAP-Verbindung bewirkt, dass eine sichere SOAP-Verbindung zu WebSphere Application Server Version 6.1 fehlschlägt. Dieses Problem tritt jedoch nicht auf, wenn der Server in der Serversicht definiert ist und der Serverstatus leer ist.
Das Problem lässt sich durch die Verwendung einer sicheren RMI-Verbindung zum Server an Stelle einer SOAP-Verbindung umgehen oder durch die Verwendung einer nicht gesicherten SOAP-Verbindung.
Wenn der ferne Server gestoppt wird, dauert es möglicherweise lange, bis der Assistent 'Neuer Server' vollständig beendet wird, nachdem Sie auf die Schaltfläche Fertig stellen geklickt haben. Sie können das Problem umgehen, indem Sie den fernen Server starten, bevor Sie im Assistenten 'Neuer Server' auf Fertig stellen klicken.
Wenn eine Datei mit der Erweiterung .war im Ordner 'EarContent' eines EAR-Projekts abgelegt wird und nicht als Webmodul in der Datei 'application.xml' definiert ist, schlägt die Publizierung der Unternehmensanwendung auf dem Server mit der folgenden Fehlernachricht fehl:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Das verschachtelte Archiv "abc.war" in "D:\myworkspace\PublishEAR\EarContent konnte nicht geöffnet werden".Dieser Fehler wird dadurch verursacht, dass die Workbench die Datei nicht ordnungsgemäß als Webmodul handhaben kann. Wählen Sie eine der folgenden Strategien zur Umgehung dieses Problems aus:
- Wenn es sich bei der Datei um ein Webmodul handelt, fügen Sie die Datei als Modul zu der Unternehmensanwendung hinzu. Genaue Informationen hierzu enthält das Thema Adding modules to an enterprise application in der Produkthilfe.
- Wenn es sich bei der Datei nicht um ein Webmodul handelt, kann das Publizierungsproblem umgangen werden, indem Sie die Dateinamenerweiterung ändern und an Stelle der Erweiterung .war beispielsweise die Erweiterung .jar angeben.
Wenn Sie bei fernem WebSphere Application Server Version 5.1 oder fernem WebSphere Application Server Version 5.1 Express Edition das Implmentierungsverzeichnis und das Publizierungsverzeichnis im Servereditor ändern und anschließend die Anwendung neu publizieren, wird die Anwendung nach wie vor auf dem vorherigen (ursprünglichen) Ziel publiziert. Dies führt dazu, dass die an den Verzeichnissen für die Publizierung und Implementierung durchgeführten Änderungen nicht übernommen werden. Dieses Problem tritt auf, wenn die Methoden 'Lokale Kopie' oder 'FTP' verwendet werden.
Zur Umgehung dieses Problems starten Sie die Workbench neu. Danach sollten die Konfigurationsänderungen an dem Publizierungsverzeichnis und dem Implementierungsverzeichnis in Kraft treten.
Als Unterstützung einer flexibleren Strategie zum Speichern von Projekten wurde das Verfahren zum Publizieren von Anwendungen geändert. Anwendungen werden nun vor ihrer Publizierung auf dem Server kopiert. Wenn Ihre Anwendung umfangreich ist und zum Beispiel größer als 100 MB ist, erfordert die Kopieroperation , die für den Publizierungsbefehl verwendet wird, zusätzliche Zeit, wodurch der Vorgang länger als in der Vorgängerversion dauert.
Gegenwärtig gibt es keine Problemumgehung. IBM arbeitet an einer Aktualisierung, bei der die Notwendigkeit für diese neue Kopieroperation in den meisten Fällen entfällt.
Wenn ein gesicherter WebSphere Application Server Version 6.1 gestartet wird und Sie im Servereditor den Serververbindungstyp entweder in RMI (Methodenaufruf über Remotezugriff) oder SOAP ändern, wird nach dem Speichern der Änderungen im Servereditor eventuell die folgende Fehlernachricht mit dem Inhalt angezeigt, 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 diesen Fehler problemlos ignorieren. Optional können Sie, nachdem in der Sicht 'Server' der Serverstatus Gestartet angezeigt wird, einen Publizierungsbefehl ausführen. Klicken Sie hierzu in der Sicht 'Server' mit der rechten Maustaste auf den Server, und wählen Sie Publizieren aus.
Wenn Sie versuchen, eine Datenquelle mit dem Assistenten 'Ersteller für Tabellen und Datenquellen' zu generieren, tritt möglicherweise ein Fehler TargetInvocationException im Abschnitt 'Details' im Dialogfenster 'Ergebnisse der Tabellen- und Datenquellenerstellung' auf.
Der Fehler 'TargetInvocationException' kann auftreten, wenn Sie einen Projektaustausch mit Datenquellen importieren, die mit dem gleichen JNDI-Namen (JNDI: Java Naming and Directory Interface) definiert wurden.
Um den Fehler 'TargetInvocationException' zu umgehen, prüfen Sie, ob in der Workbench bereits eine Datenquellen mit dem gleichen JNDI-Namen definiert ist. Sollte dies der Fall sein, entfernen Sie sie von der Seite 'Implementierung' des Editors für den Implementierungsdeskriptor der Anwendung, und erstellen Sie anschließend unter Verwendung eines anderen JNDI-Namens die Datenquelle erneut. Der JNDI-Name muss eindeutig sein, da es sich hierbei um einen Benennungs- und Suchdienst handelt, der zum Binden einer Enterprise-Bean an eine Datenquelle dient.
Wenn Sie den Server in der Sicht 'Server' stoppen, stoppt der Server möglicherweise nicht vollständig. In der Sicht 'Server' wird zwar Gestoppt angezeigt, es könnte aber sein, dass der Serverprozess nicht reagiert. Dies tritt in der Regel ein, wenn Artefakte wie beispielsweise Ihre Anwendung oder die Workbench an Verweisen auf Klassen auf dem Server festhalten. Mögliche Szenarios sind zum Beispiel:
- Anwendungen in Endlosschleifen oder Anwendungen, die an Verweisen auf manche Klassen auf dem Server festhalten
- Anwendungen, die Cloudscape- oder Derby-Datenbankverbindungen herstellen, aber nicht bereinigen
- Verwendung der Schaltfläche Verbindung testen im Assistenten 'Neue Verbindung' der Datentools, um eine Verbindung zu einer Cloudscape- oder Derby-Datenbank zu öffnen, ohne die Verbindung zur Datenbank zu trennen
Einschränkung: Mehrere gleichzeitige Verbindungen zu einer einzigen Cloudscape- oder Derby-Datenbank werden aufgrund einer Cloudscape- bzw. Derby-Konfigurationseinschränkung nicht unterstützt. Wenn Sie die Datenbankverbindung zu der Datenbank im Datenbankexplorer aufrechterhalten und der Server versucht, eine weitere Cloudscape- oder Derby-Verbindung über eine Datenquelle herzustellen, dann schlägt die zweite Verbindung fehl. Aus diesem Grund müssen Sie die Verbindung im Datenbankexplorer schließen, bevor ein Server eine Verbindung zur Cloudscape- oder Derby-Datenbank herstellen kann.
Zur Umgehung des Problems sollten Sie die Funktionen Ihres Betriebssystems zum Stoppen des java-Prozesses verwenden, auf dem der Server ausgeführt wird. Wahlweise hierzu können Sie auch die Workbench neu starten und so erzwingen, dass der Verweis freigegeben wird. Beim letzten Beispielszenario, das unter dem dritten Listenpunkt geschildert ist, können Sie die Sicht 'Datenbankexplorer' verwenden, um eine Verbindung zu einer Cloudscape- bzw. Derby-Datenbank herzustellen oder zu trennen.
Wenn Sie Ressourcen auf dem Server publizieren, zum Beispiel eine Enterprise-Bean, und Universal Test Client (UTC) zum Testen der EJB verwenden, wird die JAR-Datei gesperrt und kann nicht aktualisiert werden. Dies hat zur Folge, dass bei den Tools vorgenommene Änderungen beim Testen der EJB nicht berücksichtigt werden. Wenn UTC erst einmal die EJB-JAR-Datei lädt, bleibt die JAR-Datei so lange gesperrt, bis die Anwendung entfernt und dann erneut hinzugefügt oder bis der Server neu gestartet wird.
Die Umgehung für dieses Problem besteht darin, UTC in der Entwicklungsumgebung zu verwenden, in der die Ressourcen der Anwendung außerhalb des Arbeitsbereichs und nicht auf dem Server ausgeführt werden. Die entsprechende Konfiguration kann mit dem Assistenten 'Neuer Server' vorgenommen werden. Wahlweise kann die Einstellung auch später geändert werden, indem Sie im Servereditor die Option Server mit Ressourcen im Arbeitsbereich ausführen unter den Publizierungsoptionen auswählen. Dies ermöglicht, dass einzelne Dateien in dem EJB-Projekt aktualisiert werden können, ohne dass die gesamte EJB-JAR-Datei ersetzt werden muss.
Nachdem die Anwendung voll getestet wurde, kann sie mit der PublizierungsoptionServer mit Ressourcen auf dem Server ausführen auf dem Server publiziert werden.