Tools zum Testen und Publizieren (Publizierungsserver) - Release-Informationen

© Copyright International Business Machines Corporation 2006. All rights reserved.
© Copyright IBM Deutschland GmbH 2006. Alle Rechte vorbehalten.

Release-Informationen

1.0 Einschränkungen
   1.1 Option 'Auf den Server kopierte Anwendungsdateien minimieren' wird von WebSphere Application Server 6.0.2.5 und später unterstützt
   1.2 Entfernen eines EJB-Moduls, das von mehreren EAR-Projekten gemeinsam genutzt wird
   1.3 Ausführen von Multithread-WebSphere-Anwendungsclients
2.0 Bekannte Probleme und Problemlösungen
   2.1 Sofortige Methodenersetzung wird nicht angewendet nicht Wiederaufnahme im Debugmodus
   2.2 Schaltfläche 'Entfernen' in Dialogfenster 'Gemeinsame WebSphere-Server verwalten' funktioniert nicht
   2.3 Der Assistent 'Neuer Server' ruft eventuell nicht die korrekten Portinformationen ab
   2.4 Erstellen von Profilen für WebSphere Application Server unter einem 64-Bit-System
   2.5 Lange Verzögerung bei der Herstellung einer RMI-Verbindung nach Verlust der Netzkonnektivität
   2.6 Server kann diverse Änderungen auf der Seite 'Implementierung' im 'Editor für Implementierungsdeskriptor der Anwendung' nicht berücksichtigen
   2.7 Fehler 'java.lang.NoClassDefFoundError', wenn eine Dienstprogramm-JAR-Datei zu den Webbibliotheken hinzugefügt wird
   2.8 Zwischen WebSphere Application Server Version 6.0 und Version 6.1 ist keine Koexistenz sicherer Verbindungen möglich
   2.9 Assistent 'Neuer Server' benötigt möglicherweise länger, bis zur vollständigen Beendigung, wenn der ferne Server gestoppt wird
   2.10 Publizierung einer EAR-Anwendung mit der Dateinamenerweiterung '.war' im Verzeichnis 'EarContent' schlägt fehl
   2.11 Für ferne WebSphere Application Server Version 5.1 können Änderungen an der Implementierung nicht berücksichtigt und Verzeichnisse nicht publiziert werden
   2.12 Publizierung umfangreicher Anwendungen ist langsamer als in der vorherigen Version
   2.13 Umschalten des Serververbindungstyps für gesicherten WebSphere Application Server Version 6.1
   2.14 Auftreten des Fehlers 'TargetInvocationException' bei Verwendung des Assistenten 'Ersteller für Tabellen und Datenquellen'
   2.15 Server stoppt möglicherweise nicht vollständig, wenn er in der Sicht 'Server' gestoppt wird
   2.16 EJB-JAR-Änderungen werden nicht berücksichtigt, wenn EJB über Universal Test Client (UTC) ausgeführt wird

1.0 Einschränkungen

1.1 Option 'Auf den Server kopierte Anwendungsdateien minimieren' wird von WebSphere Application Server 6.0.2.5 und später unterstützt

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.  

1.2 Entfernen eines EJB-Moduls, das von mehreren EAR-Projekten gemeinsam genutzt 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)
 

1.3 Ausführen von Multithread-WebSphere-Anwendungsclients

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:

  1. 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
  2. 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.

2.0 Bekannte Probleme und Problemlösungen

2.1 Sofortige Methodenersetzung wird nicht angewendet nicht Wiederaufnahme im Debugmodus

Angenommen, Ihr Anwendungsclientprojekt ist wie folgt konfiguriert:

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.

2.2 Schaltfläche 'Entfernen' in Dialogfenster 'Gemeinsame WebSphere-Server verwalten' funktioniert nicht

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:

  1. Wählen Sie in der Symbolleiste Fenster > Benutzervorgaben aus. Das Dialogfenster 'Benutzervorgaben' wird geöffnet.
  2. Wählen Sie im linken Teilfenster Server > WebSphere > WebSphere v51 aus.
  3. 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.

  1. Ö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.
  2. Löschen Sie den Eintrag, der sich auf den zu entfernenden gemeinsam genutzten Server bezieht.
  3. 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.
  4. 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.

2.3 Der Assistent 'Neuer Server' ruft eventuell nicht die korrekten Portinformationen ab

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:

Problemumgehung:

  1. 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:
    PortnamePortbeschreibungStandardportnummer Ihre zugewiesene Portnummer
    SOAP_CONNECTOR_ADDRESS SOAP 8880
    BOOTSTRAP_ADDRESS RMI 2809
    WC_adminhost Administrationskonsole 9060
    WC_defaulthost HTTP-Transport 9080
  2. Um eine Verbindung zum Server herzustellen, geben Sie die korrekte RMI-Portnummer bzw. SOAP-Portnummer bei der Erstellung des Servers an.
  3. 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
  4. 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.

 

2.4 Erstellen von Profilen für WebSphere Application Server unter einem 64-Bit-System

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.

2.5 Lange Verzögerung bei der Herstellung einer RMI-Verbindung nach Verlust der Netzkonnektivität

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:

2.6 Server kann diverse Änderungen auf der Seite 'Implementierung' im 'Editor für Implementierungsdeskriptor der Anwendung' nicht berücksichtigen

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.

  1. Stoppen Sie den Server.
    1. Klicken Sie in der Sicht 'Server' auf die rechte Maustaste, und wählen Sie Stoppen aus.
    2. 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.  
  2. 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.
  3. Starten Sie den Server.
    1. Klicken Sie in der Sicht 'Server' auf die rechte Maustaste, und wählen Sie Starten aus.
    2. 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.
  4. 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.  

2.7 Fehler 'java.lang.NoClassDefFoundError', wenn eine Dienstprogramm-JAR-Datei zu den Webbibliotheken hinzugefügt wird

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:

  1. 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.
  2. Klicken Sie mit der rechten Maustaste auf das Webprojekt, und wählen Sie Eigenschaften aus. Das Dialogfenster 'Eigenschaften' wird geöffnet.
  3. Wählen Sie J2EE-Modulabhängigkeiten aus.  
  4. Wählen Sie auf der Registerkarte J2EE-Module unter der Spalte JAR/Modul das Markierungsfeld neben Ihrer Dienstprogramm-JAR-Datei aus.

2.8 Zwischen WebSphere Application Server Version 6.0 und Version 6.1 ist keine Koexistenz sicherer Verbindungen möglich

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.

 

2.9 Assistent 'Neuer Server' benötigt möglicherweise länger bis zur vollständigen Beendigung, wenn der ferne Server gestoppt wird

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.

2.10 Publizierung einer EAR-Anwendung mit der Dateinamenerweiterung '.war' im Verzeichnis 'EarContent' schlägt fehl

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:

 

2.11 Für ferne WebSphere Application Server Version 5.1 können Änderungen an der Implementierung und den Verzeichnissen für die Publizierung nicht berücksichtigt werden

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.

2.12 Publizierung umfangreicher Anwendungen ist langsamer als in der vorherigen Version

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.

2.13 Umschalten des Serververbindungstyps für gesicherten WebSphere Application Server Version 6.1

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.

2.14 Auftreten des Fehlers 'TargetInvocationException' bei Verwendung des Assistenten 'Ersteller für Tabellen und Datenquellen'

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.

2.15 Server stoppt möglicherweise nicht vollständig, wenn er in der Sicht 'Server' gestoppt wird

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:

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.

2.16 EJB-JAR-Änderungen werden nicht berücksichtigt, wenn EJB über Universal Test Client (UTC) ausgeführt wird

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.