1.0 Einführung
2.0 Unterstützte Software und Spezifikationen
3.0 Änderungen seit dem letzten Release
4.0 Einschränkungen
4.1 WebSphere-Server muss eine übereinstimmende Codepage besitzen
5.0 Bekannte Probleme
5.1 J2C-Ressourcenadapter für WebSphere v5 konfigurieren
5.2 WebSphere Application Server kann wegen ungültigen Zeichen nicht erstellt oder gestartet werden
5.3 Lange Verzeichnisnamen können zu Fehlern beim JSP-Test führen
5.4 Internet Explorer: Beim Verwenden von lokalen Adressen Proxy- oder Socks-Server inaktivieren
5.5 Probleme bei der Verwendung von Apache Tomcat bei unterbrochener Verbindung zum Internet
5.6 WebSphere-Server-Sicherheit
5.7 Java-Anwendungen ausführen, die eine Verbindung zu WebSphere Application Server herstellen
5.8 Verwaltungsclient von WebSphere V4.0 mit aktivierter Sicherheit ausführen
5.9 Versionen der WebSphere-Testumgebung
5.10 Konstruktoren im Universellen Testclient verwenden
5.11 Problem mit Groß-/Kleinschreibung beim Publizieren eines fernen V5-Servers auf Windows
5.12 Standardmäßige JNDI-Provider-URL im Universellen Testclient
5.13 J2EE-Client kann auf einer fernen Maschine nicht auf Testumgebungsserver zugreifen
5.14 Traceverarbeitung mit WebSphere Version 4.0
5.15 Nach Deinstallieren der WebSphere V4-Laufzeitumgebung sind nocht Dateien vorhanden
5.16 Nachricht beim Anwenden der temporären Korrektur (PTF) für WebSphere V4
5.17 Datenquellen und Server in der Verwaltungskonsole von WebSphere V5 erstellen
5.18 Serverkonfigurationen versetzen und Serverprojekte umbenennen
5.19 Pfadoptionen für WebSphere-Server
5.20 Fernen Server für die Verwendung der integrierten Nachrichtenübertragung konfigurieren
5.21 Nachricht 'Es wurde nur der Client für die integrierte Nachrichtenübertragung installiert' (Embedded Messaging client only has been installed) in Konsolensicht ignorieren
5.22 Cloudscape 5.1 konfigurieren
5.23 Erneutes Publizieren des WebSphere-Servers auf AIX-System verursacht eine Warnung
5.24 Unterstützung für Debug mit Höchstgeschwindigkeit (Full Speed Debug) und sofortige Methodenersetzung (Hot Method Replace)
5.25 WebSphere MQ - Migration
5.26 Migration von implemtierten Connectorprojekten aus WebSphere Studio v5.0
5.27 WebSphere-Server starten nicht, wenn Arbeitsbereichspfad mit einem Backslash beginnt
5.28 Beschädigung des Servers möglich, wenn neuer JAAS-Authentifizierungseintrag gespeichert wird
Mit der Komponente 'Servertool' können Sie J2EE-Anwendungen auf unterschiedlichen lokalen und fernen Laufzeitumgebungen testen und publizieren. Diese Readme-Datei beschreibt Einschränkungen, bekannte Probleme und Umgehungen, die mit den folgenden Servertoolfunktionen zusammenhängen:
- Einrichten des Servers unter Verwendung eines Servers und einer Serverkonfiguration. (Server und Serverkonfigurationen sind Konstrukte, die von den Servertools zum Testen und Publizieren auf unterschiedlichen Laufzeitumgebungen verwendet werden.)
- Testen von J2EE-Projekten auf IBM WebSphere Application Server oder Apache Tomcat.
- Testen von Enterprise-Beans auf dem Universellen Testclient.
- Statische Webprojektunterstützung.
Die Onlinehilfefunktion zum Testen und Publizieren enthält zusätzliche Informationen zu Einschränkungen der Servertools und zu Umgehungen bei Problemen in den Servertools.
Informationen zu unterstützten Laufzeitumgebungen finden Sie in der Readme-Datei des Produkts.
Der Universelle Testclient erfordert die Verwendung von Netscape Version 6.0 oder höher bzw. Microsoft Internet Explorer 5.0 oder höher
Die Servertools unterstützen das Testen und Publizieren von Projekten auf WebSphere-Servern unter Windows, Linux und AIX.
Beim Testen mit fernen WebSphere-Servern muss die Codepage des fernen Systems identisch mit der Codepage des lokalen Systems sein. Das Ausführen von einem lokalen Server und einem fernen Server mit unterschiedlichen Codepages wird nicht unterstützt und kann die Konsole beschädigen.
Wenn Sie auf der J2C-Seite im Serverkonfigurationseditor von WebSphere V5 auf 'Hinzufügen' klicken, wird möglicherweise ein Fehler angezeigt. Um dieses Problem zu umgehen, konfigurieren Sie anstatt dessen das Connectormodul in einer EAR oder führen Sie die folgenden Schritte aus:
1. Aktivieren Sie die Administrationskonsole von WebSphere und starten Sie den Server.
2. Öffnen Sie die Administrationskonsole und melden Sie sich an. Wählen Sie links Ressourcen > Ressourcenadapter aus.
3. Klicken Sie auf Neu. Geben Sie bei Name den Namen des Connectormoduls ein und geben Sie den vollständig qualifizierten Pfad zum Ordner 'connectorModule' in Ihrem Projekt an. Beispiel: C:\workspace\meinConnector\connectorModule.
4. Klicken Sie auf Anwenden und anschließend auf Aktualisieren, damit das Serverprojekt in der IDE aktualisiert wird. Sie können jetzt mit dem Serverkonfigurationseditors weiterarbeiten und die gewünschten Änderungen vornehmen.
Wenn Sie WebSphere Studio in einem Verzeichnis installieren, dessen Name ein Dollarzeichen ($) oder sonstige ungewöhnliche Zeichen wie die Raute (#), das Prozentzeichen (%), das Pluszeichen (+) oder den Stern (*) enthält, kann der WebSphere-Server möglicherweise nicht erstellt oder erfolgreich gestartet werden. Installieren Sie aus diesem Grund WebSphere Studio nicht in einem Verzeichnis, dessen Name eines dieser Zeichen enthält.
Wenn Sie einen WebSphere-Server oder ein Serverprojekt erstellen, das einen WebSphere-Server enthalten wird, verwenden Sie keine der folgenden Zeichen in dem Namen: #, %, & oder *. WebSphere Application Server unterstützt diese Zeichen nicht.
Wenn Sie einen Arbeitsbereich in einem Verzeichnis mit einem langen Pfad installieren oder lange Namen für Ihr Unternehmensanwendungs- oder Webprojekt auswählen, erhalten Sie möglicherweise die folgende Fehlernachricht, wenn Sie versuchen, eine JSP-Seite auszuführen:
Fehlermeldung: JSPG0113E: JSP-Datei
"Xxx/Yyy_jsp_0.java (Dateiname zu lang)" nicht gefunden (Error Message: JSPG0113E: JSP file "Xxx/Yyy_jsp_0.java (Filename too long)" not found)Wenn Sie diese Fehlernachricht empfangen, können Sie eine der folgenden Aktionen ausführen:
- Installieren Sie Ihren Arbeitsbereich an einer Position mit einem kürzeren Namen, z. B. c:/workspace.
- Benennen Sie Ihr Unternehmensanwendungsprojekt und/oder Webprojekt so um, dass es einen kürzeren Namen hat.
- Verringern Sie die Ordnertiefe von JSP-Seiten innerhalb der Webanwendung. Verschieben Sie die JSP-Seiten z. B. in einen allgemeinen Ordner oder ein allgemeines Stammverzeichnis des Ordners 'Web Content' anstelle einer tieferen Verschachtelung.
Wenn Sie einen Proxy- oder Socks-Server im Internet Explorer verwenden, sollten Sie ihn für lokale Adressen inaktivieren. Andernfalls können Probleme auftreten, wenn Sie versuchen, den Universellen Testclient oder eine andere Webanwendung anzuzeigen und dazu entweder den internen Webbrowser oder Ihre installierte Version von Microsoft Internet Explorer verwenden.
Die Standarddatei für web.xml, die mit Apache Tomcat geliefert wird, enthält einen Verweis auf eine DTD-Datei im Internet. Aus diesem Grund starten Tomcat-Server nicht, wenn die Verbindung zum Internet unterbrochen ist. In WebSphere Studio wurden diese Verweise aus der Konfiguration von Tomcat Version 3.2 gelöscht, so dass Sie im Standalone-Modus arbeiten können. Wenn Sie eine Tomcat-Serverkonfiguration von außerhalb von WebSphere Studio importieren oder Tomcat Version 4.0 verwenden, treten möglicherweise Probleme auf, wenn die Verbindung zum Internet unterbrochen ist. Führen Sie in diesem Fall folgende Schritte aus, um den betreffenden Verweis zu löschen:
Wenn Probleme beim Starten des Servers auftreten, müssen Sie möglicherweise eine Verbindung zum Internet herstellen und das DOCTYPE-Element unter Verwendung der Sicherungsdatei web.xml wieder hinzufügen.
- Erstellen Sie eine Sicherungskopie der Datei web.xml von Ihrer Tomcat-Serverkonfiguration.
- Bearbeiten Sie die Datei web.xml in Ihrer Tomcat-Serverkonfiguration mit Hilfe eines Texteditors.
- Löschen Sie das gesamte DOCTYPE-Element aus der Datei.
- Speichern Sie, und schließen Sie den Editor.
Vergeben Sie beim Aktivieren der Sicherheitsfunktion für einen Server keine Server-ID mit demselben Namen wie die Maschine, auf der der WebSphere Application Server installiert ist. Andernfalls kann der WebSphere Application Server möglicherweise nicht gestartet werden.
Die Richtlinie für die Benutzerberechtigungen für die Server-Benutzer-ID muss dem Benutzer die Berechtigung für Act as part of the operating system (Als Teil des Betriebssystems agieren) erteilen.
WebSphere Application Server weist die folgende Einschränkung auf: Alle Java-Anwendungen, die den WebSphere-Client verwenden, um eine Verbindung mit auf einem Webserver ausgeführten Enterprise-Beans herzustellen, müssen die gleiche IBM Java ORB-Stufe verwenden, die zur Erstellung des WebSphere-Clients verwendet wurde. Wenn Sie nicht die gleiche ORB-Stufe verwenden, kann der folgende Fehler beim Ausführen der Clientanwendung angezeigt werden:
java.lang.NoClassDefFoundError: com/ibm/rmi/iiop/GIOPVersionException
Um sicherzustellen, dass die gleiche ORB-Stufe verwendet wird, können Sie die Clientanwendung unter Verwendung von WebSphere JRE ausführen. Führen Sie dazu die folgenden Schritte aus:
- Öffnen Sie unter Verwendung der Menüpunkte 'Ausführen > Ausführen' oder 'Ausführen > Debug' in der Debug-Perspektive den Dialog zum Starten von Konfigurationen.
- Wählen Sie die zu bearbeitende Startkonfiguration der Java-Anwendung aus.
- Gehen Sie auf die JRE-Seite und wählen Sie die entsprechende WebSphere-JRE aus dem kombinierten Feld aus.
- Nehmen Sie die Änderungen vor.
Alternativ können Sie die Clientanwendung mit einer beliebigen JRE ausführen, sofern Sie sicherstellen, dass die übereinstimmende ORB-Stufe verwendet wird. Führen Sie dazu die folgenden Schritte aus:
- Öffnen Sie unter Verwendung der Menüpunkte 'Ausführen > Ausführen' oder 'Ausführen > Debug' in der Debug-Perspektive den Dialog zum Starten von Konfigurationen.
- Wählen Sie die zu bearbeitende Startkonfiguration der Java-Anwendung aus.
- Gehen Sie auf die Seite 'Argumente' und führen Sie Folgendes zum Feld 'VM-Argumente' hinzu:
-Xbootclasspath/p:WAS_installdir\java\jre\lib\ext\ibmorb.jar
wobei WAS_installdir das Verzeichnis ist, das die Laufzeit enthält, z. B. c:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4- Nehmen Sie die Änderungen vor.
Der WebSphere-Verwaltungsclient der Version 4 kann nicht direkt von der Workbench gestartet werden, wenn die Sicherheit aktiviert ist. Zum Starten des Verwaltungsclients befolgen Sie die folgenden Schritte:
- Starten Sie den WebSphere-Server.
- Öffnen Sie einen Webbrowser, und geben Sie die folgende URL ein: http://[localhost:8080]/admin; hierbei ist [localhost:8080] der Servername und der Serverport, den Sie verwenden.
- Geben Sie die Benutzer-ID und das Kennwort ein, die/das Sie zur Konfiguration der Sicherheit verwendet haben. Klicken Sie auf Übergeben.
- Klicken Sie im rechten Teilfenster auf Konfiguration > Öffnen.
- Wählen Sie Vollständigen Pfad der Datei auf dem Server eingeben aus.
- Geben Sie den vollständigen Pfad für Ihre Serverkonfiguration im Textfeld ein. Beispiel:C:\studio\eclipse\workspace\Servers\was.wsc\server-cfg.xml.
- Klicken Sie auf OK.
Die WebSphere-Testumgebung Version 4 basiert auf WebSphere Version 4.06. Die WebSphere-Testumgebung Version 5 basiert auf WebSphere Version 5.02. Wenn Sie von einer vorhergehenden Version von WebSphere Studio migrieren, werden alle e-fixes zu der WebSphere-Testumgebung entfernt, und Sie müssen diese anschließend manuell erneut installieren.
Bei Verwendung des Universellen Testclients können Sie keine Objekte konstruieren, die auf der Parameterseite Schnittstellen als Parameter verwenden. Alle Objekte, die aus Parametern mit Schnittstellentypen konstruiert werden sollen, müssen den Abschnitt 'Klassenverweise' verwenden.
Laden und konstruieren Sie zuerst ein Objekt vom Typ 'Schnittstelle' oder 'abstrakt'. Laden Sie anschließend die Klasse, die den Konstruktor mit dem abstrakten Typ/Schnittstellentyp enthält. Wählen Sie nun das zuvor erstellte Objekt auf der Parameterseite aus.
Wurde ein Projekt auf einen fernen V5-Server unter Windows publiziert, und das Projekt wurde mit demselben Namen in unterschiedlicher Groß-/Kleinschreibung benannt (z. B. 'MyEarProject' wird zu 'myearproject'), kann während dem Serverstart mehrmals der Fehler Datei existiert nicht (File does not exist) auftreten. Eine Einschränkung in Windows ist der Grund, warum WebSphere Studio zwei publizierte Projekte mit demselben Namen und unterschiedlicher Groß-/Kleinschreibung nicht unterscheiden kann. Sie können das Problem lösen, indem Sie die publizierte Serverkonfiguration manuell von der fernen Maschine entfernen und das Projekt dann erneut publizieren.
Die standardmäßige JNDI-Provider-URL für den Universellen Testclient von WebSphere Studio Version 4.0 wurde geändert. Die neue Provider-URL ist 'iiop://2809' anstelle von 'iiop://900'. Wenn Sie den Testclient manuell starten möchten und die alte Portnummer benötigen (z. B. um auf WebSphere Version 4.0 zuzugreifen), ändern Sie auf der Eigenschaftenseite des Testclient die Provider-URL.
Möglicherweise erhalten Sie die Fehlermeldung org.omg.CORBA.COMM_FAILURE, wenn Sie versuchen, von einem auf einer fernen Maschine ausgeführten J2EE-Client auf einen Testumgebungsserver zuzugreifen. Um das Problem zu beheben, müssen Sie den Namen des ORB-Bootstrap-Hosts, der in der Konfiguration des fernen Servers definiert ist, konfigurieren. Bearbeiten Sie den Namen des ORB-Bootstrap-Hosts, indem Sie im Server-Editor zur Seite Ports wechseln und für das Feld Hostname unter dem Abschnitt für den ORB-Bootstrap-Port den Namen des fernen Hosts angeben.
Wenn Sie die Änderungen durchgeführt haben, speichern Sie sie und starten Sie den Testumgebungsserver erneut, damit die Änderungen in Kraft treten.
Inaktivieren Sie die Traceverarbeitung für WebSphere Version 4.0, erhalten Sie in der Konsole eine ConnectionException und können den Server nicht mehr korrekt stoppen.
Nach dem Deinstallieren der WebSphere V4-Laufzeit ist unter Umständen das Verzeichnis WS_installationsverzeichnis/runtimes/aes_v4 noch vorhanden, obwohl die Deinstallation ausgeführt wurde. In diesem Fall müssen Sie das Verzeichnis manuell entfernen. Ansonsten können Probleme bei der WebSphere V4-Serverunterstützung auftreten. Die gleiche manuelle Überprüfung muss ausgeführt werden, wenn WebSphere Studio deinstalliert und dann in derselben Speicherposition erneut installiert wird.
Wenn Sie die temporäre Korrektur (PTF) für WebSphere V4 anwenden, wird möglicherweise die folgende Nachricht angezeigt: 'HINWEIS: Bitte generieren Sie die Pluginkonfiguration neu, nachdem der Server gestartet wurde, damit die Datei 'plugin-cfg.xml' aktualsiert wird. (NOTE: Please regenerate the plugin configuration once the server is started in order to update the plugin-cfg.xml file.) Sie können diese Nachricht problemlos ignorieren.
Eventuell erhalten Sie eine 'NullPointerException'-Ausnahme oder andere Fehler, wenn Sie mit der Verwaltungskonsole von WebSphere in WebSphere Studio Datenquellen hinzufügen oder Server erstellen. Sie umgehen den Fehler, indem Sie eine der folgenden Lösungen anwenden:
- Wenn Sie eine Datenquelle erstellen, verwenden Sie stattdessen den Server-Editor von WebSphere V5. Sie öffnen den Editor, indem Sie entweder in der Sicht 'Server' oder 'Serverkonfiguration' auf den WebSphere V5-Server doppelklicken. Wechseln Sie zur Seite 'Datenquelle', um Datenquellen zum Server hinzuzufügen, zu bearbeiten oder vom Server zu entfernen.
- Stoppen Sie den Server.
- Kopieren Sie das Verzeichnis der Schablonen von folgendem Verzeichnis (wobei WS_installationsverzeichnis das Verzeichnis angibt, in dem WebSphere Studio installiert ist):
WS_installationsverzeichnis\runtimes\base_v5\config\templates
in den aktuellen Arbeitsbereich unter den folgenden Ordner:
workspace_ verzeichnis\server_ projekt\server_ name.wsc- Starten Sie den Server neu und wiederholen Sie den Versuch.
Die Zuordnung zwischen einem Server und seiner Serverkonfiguration schließt das Projekt ein, in dem sich die Serverkonfiguration befindet. Wenn Sie ein Serverprojekt umbenennen oder eine Serverkonfiguration zu einem anderen Projekt versetzen, werden die Zuordnungen aller Server, die diese Konfigurationen verwenden, unterbrochen. Um das Problem zu beseitigen, klicken Sie in der Sicht 'Server' mit der rechten Maustaste auf den Server und wählen Sie die Option Konfiguration wechseln > serverkonfigurationsname aus, um die Konfiguration erneut dem Server zuzuordnen.
Die Funktionalität für Pfadoptionen auf der Seite 'Umgebung' im WebSphere-Server-Editor funktioniert nicht. Der Pfad, der im Feld Java-Bibliothekpfad eingegeben wird, wird zum vorhandenen Serverpfad hinzugefügt. Sie haben keinerlei Möglichkeit, zu steuern, an welcher Stelle Daten hinzugefügt werden, zum Beispiel, ob die Daten zum Anfang, in der Mitte oder am Ende des vorhandenen Serverpfads hinzugefügt werden oder diesen gänzlich ersetzen.
In dem Thema, das die Konfiguration des Servers für die Verwendung der integrierten Nachrichtenübertragung (Messaging) zum Inhalt hat, gelten einige Teile des Abschnitts zur Testumgebung für die Anweisungen im Abschnitt Ferne Server . Folgendes muss bei der Konfiguration eines lokalen oder eines fernen Servers definiert werden:: WAS_PUBSUB_ROOT, MQ_INSTALL_ROOT und ein Warteschlangenmanager auf der Serverseite. Zusätzlich muss ein Eintrag im Abschnitt 'ws.ext.dirs' der Serverkonfiguration vorhanden sein, der auf das Verzeichnis java/lib verweist, in dem WebSphere MQ installiert ist.
Anweisungen zur Konfiguration des Warteschlangenmanagers enthält der Abschnitt Testumgebung dieses Themas. Dieselbe Stapeldatei 'createmq' ist auch auf einem eigenständigen WebSphere Application Server-System in demselben Verzeichnis relativ zum Stammverzeichnis von WebSphere Application Server vorhanden. Sie müssen diese Schritt ausführen, wenn Sie Ihren Server über Remotezugriff von WebSphere Studio auf einem fernen WebSphere Application Server-System implementieren.
Hinweis: Wenn Sie die integrierte Nachrichtenübertragung (Messaging) mit dem Installationsprogramm von WebSphere Studio installiert haben, ist es nicht erforderlich, die Datei 'createmq.bat' auszuführen, die Datei 'variables.xml' zu konfigurieren oder eine Stapeldatei zum Starten der Workbench zu erstellen, die das Vorhandensein von MQ-Binärdateien im WAS-Serverpfad sicherstellen. Sie müssen jedoch trotzdem noch die Ergänzung von 'ws.ext.dirs' auf dem Server vornehmen. Dies ist nur dann erforderlich, wenn Sie die integrierte Nachrichtenübertragung (Messaging) mit dem Installationsprogramm von WebSphere Application Server installiert haben.
Während des Systemstarts der WebSphere V5.0-Testumgebung wird möglicherweise in der Konsolensicht eine Nachricht mit folgendem Inhalt angezeigt: 'Es wurde nur der Client für die integrierte Nachrichtenübertragung installiert' (Embedded Messaging client only has been installed). Dies kann erfolgen, selbst wenn die integrierte Nachrichtenübertragung (Messaging), bei der es sich um eine optionale Komponente handelt, nicht als Teil der WebSphere Studio-Installation installiert wurde. Diese Nachricht kann problemlos ignoriert werden und bedeutet nicht, dass die integrierte Nachrichtenübertragung installiert wurde, sondern vielmehr, dass bestimmte Serverkonfigurationsvariablen für den Testserver konfiguriert sind, wodurch diese missverständliche Nachricht generiert wird.
Führen Sie zum Installieren von Cloudscape 5.1 unter Windows die Datei 'installCloudscape51.bat' und unter Linux die Datei 'Cloudscape51.sh' aus. Diese Datei befindet sich im Verzeichnis WS_installationsverzeichnis/runtimes/base_v5/cloudscape51, wobei WS_installationsverzeichnis das Verzeichnis angibt, in dem WebSphere Studio installiert wurde. Das Installationsprogramm startet ein für WebSphere spezifisches Installationsprogramm für die Installation von Cloudscape. Wenn Sie aufgefordert werden, den Verzeichnisnamen anzugeben, durchsuchen Sie das Verzeichnis WS_installationsverzeichnis/runtimes/base_v5 oder geben Sie es an.
Hinweis: Nachdem Sie Cloudscape 5.1 installiert haben, ist es nicht mehr möglich, durch Cloudscape 5.0 definierte Datenquellen zu haben oder auszuführen. Falls Sie Cloudscape 5.0 ausführen wollen, müssen Sie zuerst Cloudscape 5.1 deinstallieren und anschließend die Datenquellen von Cloudscape 5.1 entfernen oder diese Datenquellen in Datenquellen für Cloudscape 5.0 ändern.
Beim erneuten Publizieren eines WebSphere-Servers auf einem AIX-System werden möglicherweise Warnungen mit dem Inhalt angezeigt, dass manche Dateien im Dialogfenster 'Publizieren' nicht gelöscht werden konnten. Sie können diese Warnungen problemlos ignorieren.
Debugs mit Höchstgeschwindigkeit (Full Speed Debug) und die sofortige Methodenersetzung (Hot Method Replace) werden nur beim Debug in der WebSphere V5-Testumgebung unterstützt. Das Debug von Anwendungen außerhalb der WebSphere V5-Testumgebung wird nicht unterstützt.
Die WebSphere-Komponente MQ unterstützt keine versionsübergreifende Kompatibilität. Sie sollten sicherstellen, dass die von Ihnen verwendete Version von WebSphere MQ dieselbe Fixpackstufe aufweist wie die WebSphere-Testumgebung oder der WebSphere-Server, auf dem die Implementierung erfolgt.
Sie sollten zum Beispiel nicht WebSphere MQ als Teil der Installation von WebSphere Studio v5.0 in Verbindung mit einer Testumgebung von WebSphere v5.0.2 verwenden. Stattdessen sollten Sie WebSphere MQ deinstallieren und die mit WebSphere Studio v5.1 ausgelieferte Version installieren.
Arbeitsbereiche, die in WebSphere Studio v5.0 erstellt wurden und Connectorprojekte enthalten, die in einer WebSphere-Testumgebung oder einem WebSphere-Server implementiert sind, werden nicht automatisch migriert, sobald ein Upgrade auf eine höhere Releasestufe ausgeführt wird. Sie erhalten möglicherweise Fehlermeldungen, wenn Sie versuchen, die Connectorprojekte auf dem Server zu publizieren.
Um das Problem zu umgehen, klicken Sie in der Sicht 'Server' mit der rechten Maustaste auf den Server, und wählen Sie die Option Projekte hinzufügen oder entfernen aus. Entfernen Sie das EAR-Projekt vom Server und fügen Sie es anschließend wieder hinzu. Hierdurch wird die WebSphere-Serverkonfiguration korrigiert, sodass die Connectorprojekte korrekt implementiert werden.
WebSphere-Server starten möglicherweise nicht, wenn ein Arbeitsbereichspfad verwendet wird, der mit einem Backslash beginnt. Arbeitsbereichspfade, die dieses Problem verursachen, sind zum Beispiel:
\workspaceA\my_workspaces\work1Arbeitsbereichspfade, die mit einem Laufwerkbuchstaben anfangen oder nicht mit einem Backslash beginnen, verursachen dieses Problem nicht. Wenn Sie WebSphere Studio bereits mit einem Arbeitsbereich gestartet haben, dessen Pfad mit einem Backslash beginnt, führen Sie die folgenden Schritte aus, um zu gewährleisten, dass die WebSphere-Server gestartet werden können:
- Schließen Sie WebSphere Studio.
- Starten Sie WebSphere Studio neu. (Verwenden Sie die Markierung -setworkspace, falls Sie zu einem früheren Zeitpunkt angegeben haben, dass der Dialog für die Arbeitsbereichsauswahl beim Systemstart nicht angezeigt werden soll).
- Wenn Sie aufgefordert werden, die Arbeitsbereichsposition anzugeben, fügen Sie den Laufwerkbuchstaben am Anfang des Arbeitsbereichspfads hinzu. Auf diese Weise müsste \workspace1 in c:\workspace1 geändert werden.
- Sie können jetzt Ihren vorhandenen WebSphere-Server starten.
Wenn Sie einen Server-Editor der Version 5 öffnen, einen neuen JAAS-Authentifizierungseintrag erstellen und diesen speichern, ohne den Editor zu verlassen, und anschließend zu der Registerkarte der Datenquelle wechseln und dort eine Datenquelle der Version 5 hinzufügen, wird der Dialog Datei geändert angezeigt. Sie müssen auf Nein klicken, um Schäden an der Serverkonfiguration zu vermeiden.
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved. (C) Copyright IBM Deutschland GmbH 2000, 2003. Alle Rechte vorbehalten.