Zugriffsfehler nach Aktivierung der Sicherheitskomponente
Verwenden Sie diese Informationen, wenn nach dem Aktivieren der Sicherheit Zugriffsprobleme auftreten.
- Nach dem Aktivieren der Sicherheitskomponente ist der partielle bzw. vollständige Zugriff auf die Administrationskonsole oder die Verwendung des Tools wsadmin nicht möglich
- Nach dem Aktivieren der Sicherheitskomponente ist der Zugriff auf eine Webseite nicht möglich
- Authentifizierungsfehler beim Zugriff auf eine Webseite
- Berechtigungsfehler beim Zugriff auf eine Webseite
- Nach dem Aktivieren der Sicherheitskomponente kann der Client nicht auf eine Enterprise-Bean zugreifen
- Der Client wird nicht zur Eingabe von Daten aufgefordert, wenn er auf eine gesicherte Enterprise-Bean zugreift
- Nach dem Aktivieren der Sicherheitskomponente kann ein Anwendungsserver, Knotenmanager oder Knoten nicht gestoppt werden
Ausnahme des Typs AccessControlException in SystemOut.log
- Nach dem Aktivieren von SSO (Single Sign-On) kann die Anmeldung an der Administrationskonsole nicht mehr durchgeführt werden
- SECJ0306E: Es wurde kein empfangener oder Aufrufberechtigungsnachweis im Thread gefunden.
- Ein NameNotFoundException-Fehler tritt auf, wenn zum ersten Mal eine Verbindung zu den eingebundenen Repositorys hergestellt wird
Allgemeine Hinweise zur Diagnose und Behebung sicherheitsbezogener Fehler enthält
der Artikel Tipps zur Fehlerbehebung bei Sicherheitskomponenten.
Falls Sie kein Problem finden, das Ihrem Problem gleicht, oder falls
Sie das Problem mit bereitgestellten Informationen nicht beheben können, suchen Sie in der Hilfe zur Fehlerbehebung
von IBM nach weiteren Informationen.
Nach dem Aktivieren der Sicherheitskomponente ist der partielle bzw. vollständige Zugriff auf die Administrationskonsole oder die Verwendung des Tools wsadmin nicht möglich
Sollten Sie nicht auf die Administrationskonsole zugreifen können oder bestimmte Objekte nicht anzeigen oder aktualisieren können, suchen Sie im Protokoll SystemOut des Anwendungsservers, in dem sich die Seite der Administrationskonsole befindet, nach einer diesbezüglichen Fehlernachricht.
Sollten Sie nicht auf die Administrationskonsole zugreifen können oder bestimmte Objekte nicht anzeigen oder aktualisieren können, suchen Sie in den Protokollen des Anwendungsservers, in dem sich die Seite der Administrationskonsole befindet, nach einer diesbezüglichen Fehlernachricht.
Anmerkung: Sie benötigen für die nächsten beiden Punkte die Administrationskonsole. Sollten Sie Probleme beim Zugriff auf die Administrationskonsole haben, müssen Sie die Sicherheit inaktivieren und die Administrationskonsole erneut starten. Geben Sie zum Inaktivieren der Sicherheit an der Eingabeaufforderung den folgenden Befehl ein:
Geben Sie Folgendes ein, wenn die Eingabeaufforderung wieder angezeigt wird:wsadmin.sh -conntype NONE
Starten Sie den Deployment Manager erneut, nachdem Sie die Sicherheit inaktiviert haben.securityoff
- Möglicherweise hat Ihre ID keine Berechtigung für Verwaltungstasks.
Dieses
Problem wird angezeigt durch Fehlermeldungen wie die folgenden:
- [8/2/02 10:36:49:722 CDT] 4365c0d9 RoleBasedAuth A CWSCJ0305A: Die rollenbasierte Berechtigungsprüfung ist für den Sicherheitsnamen MeinServer/MeineBenutzer-ID mit der Zugriffs-ID MeinServer/S-1-5-21-882015564-4266526380-2569651501-1005 beim Abruf der Methode getProcessTyp für Ressource Server und Modul Server fehlgeschlagen.
- Ausnahmenachricht: "CWWMN0022E: Der Zugriff auf die Operation getProcessType in der MBean "Server" wurde verweigert."
- Beim Ausführen des Befehls wird folgende Fehlernachricht angezeigt: wsadmin -username j2ee -password j2ee: CWWAX7246E: Es kann keine Verbindung vom Typ "SOAP" zu Host "BIRKT20" hergestellt werden, weil ein Authentifizierungsfehler aufgetreten ist. Vergewissern Sie sich, dass der Benutzer und das Kennwort in der Befehlszeile bzw. in einer Eigenschaftendatei richtig angegeben wurden.
- Vergewissern Sie sich, dass die Funktionalität der gesicherten Anwendung aktiviert ist. Die Funktionalität der gesicherten Anwendung ist aktiviert, wenn WebSphere Application Server SAF-Lesezugriff auf die RACF-Klasse FACILITY und das Profil BBO.TRUSTEDAPPS.<Kurzname_der_Zelle>.<Kurzname_des_Clusters> hat.
![[z/OS]](../images/ngzos.gif)
Nach dem Aktivieren der Sicherheitskomponente ist der Zugriff auf eine Webseite nicht möglich
- Authentifizierungsfehler - Die Sicherheit von WebSphere Application Server kann die ID der
Person oder des Prozesses nicht identifizieren. Symptome von Authentifizierungsfehlern:Auf einem Netscape-Browser:
- Nach einem Anmeldeversuch wird die Nachricht Berechtigung fehlgeschlagen. Wiederholen? angezeigt.
- Eine beliebige Anzahl von Anmeldeversuchen wird zugelassen. Wenn die Option "Abbrechen" ausgewählt wird, um die Wiederholung zu stoppen, wird die Nachricht Error 401 angezeigt.
- Typische Browser-Nachricht: Error 401: Basic realm='Default Realm'.
Browser Internet Explorer:- Nach einem Anmeldeversuch wird der Anmeldedialog erneut angezeigt.
- Lässt drei Versuche zur Wiederholung der Anmeldung zu.
- Zeigt nach drei erfolglosen Wiederholungen die Nachricht Error 401 an.
- Berechtigungsfehler - Die Sicherheitskomponente hat festgestellt, dass die Person bzw. der Prozess, die bzw. der
die Anforderung abgesetzt hat, nicht berechtigt ist, auf die geschützte Ressource
zuzugreifen. Symptome von Berechtigungsfehlern:
- Netscape: Nachricht "Error 403: AuthorizationFailed" wird angezeigt.
- Internet Explorer:
- Nachricht "You are not authorized to view this page message" wird angezeigt.
- Fehlernachricht "HTTP 403 Forbidden" wird ebenfalls angezeigt.
- SSL-Fehler - Die Sicherheit von WebSphere Application Server verwendet intern die SSL-Technologie (Secure Sockets Layer), um Übertragungen zu schützen und zu verschlüsseln.
Wenn die internen SSL-Einstellungen nicht ordnungsgemäß konfiguriert sind, kann dies zu Problemen führen. Möglicherweise haben Sie auch die SSL-Verschlüsselung für die Datenübertragungen Ihrer Webanwendung oder Ihres
Enterprise-Bean-Clients aktiviert. Falls Sie dabei falsche Konfigurationswerte
angegeben haben, kann dies unabhängig davon, ob die Sicherheit von WebSphere Application Server aktiviert ist, zu Problemen führen.
- SSL-Fehler werden häufig durch Fehlernachrichten angezeigt, die eine Anweisung wie Fehler: Der Ausgangskontext konnte nicht abgerufen werden, oder der Anfangskontext wurde nicht gefunden. Prozess wird beendet. enthalten und denen eine Ausnahme vom Typ javax.net.ssl.SSLHandshakeException folgt.
Nach dem Aktivieren der Sicherheitskomponente kann der Client nicht auf eine Enterprise-Bean zugreifen
- Lesen Sie nach, mit welchen Schritten Sie die Ressourcen schützen und die Zugriffsberechtigung für die Ressourcen erteilen.
Durchsuchen Sie die JVM-Protokolle des Servers nach Fehlern, die sich auf den Enterprise-Bean-Zugriff und -Schutz beziehen. Prüfen Sie alle Fehler in der Nachrichtentabelle.
Durchsuchen Sie die Serverprotokolle nach Fehlern, die sich auf den Enterprise-Bean-Zugriff und -Schutz beziehen. Prüfen Sie alle Fehler in der Nachrichtentabelle.
Fehler wie "Authentifizierung für /UNAUTHENTICATED beim Aufrufen von Ressource securityName:/UNAUTHENTICATED fehlgeschlagen; accessId:UNAUTHENTICATED wurden keine der erforderlichen Rollen erteilt." zeigen Folgendes an:- Ein ungeschütztes Servlet oder eine JSP hat auf eine geschützte Enterprise-Bean zugegriffen. Wenn auf ein ungeschütztes Servlet zugegriffen wird, wird der Benutzer nicht
aufgefordert, sich anzumelden, daher wird das Servlet mit der Benutzer-ID UNAUTHENTICATED
ausgeführt.
Wenn das Servlet eine geschützte Enterprise-Bean aufruft, schlägt der Aufruf fehl.
Zur Behebung dieses Fehlers müssen Sie das Servlet, das auf die geschützte Enterprise-Bean zugreift, schützen. Vergewissern Sie sich, dass für die RunAs-Eigenschaft eine ID angegeben ist, die auf die Enterprise-Bean zugreifen kann.
- Ein nicht authentifiziertes Java-Clientprogramm greift auf eine geschützte Enterprise-Bean-Ressource zu. Das kann der
Fall sein, wenn für die von der Eigenschaftendatei sas.client.props
gelesene und vom Clientprogramm verwendete Datei das Flag securityEnabled auf
true gesetzt wurde.
Zur Lösung dieses Problems müssen Sie sicherstellen, dass für die Datei sas.client.props auf der Clientseite das Flag securityEnabled auf true gesetzt wurde.
Fehler wie "Authentifizierung für gültiger_Benutzer beim Aufrufen von Ressource securityName:/username fehlgeschlagen;accessId:xxxxxx wurden keine der erforderlichen Rollen erteilt." zeigen an, dass ein Client versucht hat, auf eine geschützte Enterprise-Bean-Ressource zuzugreifen und der bereitgestellten Benutzer-ID die erforderlichen Rollen für diese Enterprise-Bean nicht zugeordnet wurden.- Prüfen Sie, ob der Zugriff auf die erforderlichen Rollen für die Enterprise-Bean-Ressource erfolgt. Zeigen Sie die erforderlichen Rollen für die Enterprise-Bean-Ressource im Implementierungsdeskriptor der Webressource an.
- Prüfen Sie die Berechtigungstabelle, und vergewissern Sie sich, dass dem Benutzer bzw. der Gruppe, zu der der Benutzer gehört, eine der erforderlichen Rollen zugeordnet wurde. Sie können die Berechtigungstabelle für die Anwendung, die die Enterprise-Bean-Ressource enthält, auch in der Administrationskonsole anzeigen.
- Ein ungeschütztes Servlet oder eine JSP hat auf eine geschützte Enterprise-Bean zugegriffen. Wenn auf ein ungeschütztes Servlet zugegriffen wird, wird der Benutzer nicht
aufgefordert, sich anzumelden, daher wird das Servlet mit der Benutzer-ID UNAUTHENTICATED
ausgeführt.
Wenn das Servlet eine geschützte Enterprise-Bean aufruft, schlägt der Aufruf fehl.
Wenn Sie LocalOS- und SAF-Berechtigung verwenden, überprüfen Sie die SAF-EJBROLEs-Konfiguration. Stellen Sie Folgendes sicher:
- Die Klasse EJBROLE wurde aktiviert.
- Die Rolle wurde in SAF definiert.
- Die Benutzer-ID wurde für den die Rolle payroll-department berechtigt.
- Die Klasse wurde nach der Berechtigungserteilung aktualisiert.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Beginnen Sie damit, dass Sie den Text der Ausnahme hinter WSSecurityContext.acceptSecContext(), reason: anzeigen. Normalerweise wird der Fehler ohne weitere Analyse beschrieben.
- Ist diese Beschreibung nicht ausreichend, prüfen
Sie die CORBA-Minor-Codes. Diese Codes sind in den Referenzinformationen zur
Fehlerbehebung bei den
Sicherheitskomponenten in diesem Dokument enthalten.In der folgenden Ausnahme ist z. B. der CORBA-Minor-Code 49424300 aufgeführt: Die Fehlerursache gemäß der Tabelle mit dem CORBA-Minor-Code lautet:
Mit anderen Worten, in diesem Fall ist die Benutzer-ID bzw. das Kennwort, die bzw. das vom Clientprogramm bereitgestellt wurde, wahrscheinlich ungültig:authentication failed error
org.omg.CORBA.NO_PERMISSION: Caught WSSecurityContextException in WSSecurityContext.acceptSecContext(), reason: Major Code[0] Minor Code[0] Message[ Exception caught invoking authenticateBasicAuthData from SecurityServer for user jdoe. Ursache: com.ibm.WebSphereSecurity.AuthenticationFailedException] minor code: 49424300 completed: No at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code (PrincipalAuthFailReason.java:83)
Das Clientprogramm hat vom Server
eine Ausnahme des Typs CORBA INITIALIZE mit dem eingebettetem
Fehler CWWSA1477W: Abweichung bei den Sicherheitskonfigurationen von Client und
Server empfangen.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Ausnahme empfangen: org.omg.CORBA.INITIALIZE:
CWWSA1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH:
Die Sicherheitskonfiguration des Client (sas.client.props oder Einstellungen in der
grafischen Benutzerschnittstelle) bieten keine Unterstützung für die
Sicherheitskonfiguration des Servers. Gründe:
FEHLER 1: CWWSA0607E: Der Client erfordert SSL-Vertraulichkeit, aber der
Server unterstützt diese Option nicht.
FEHLER 2: CWWSA0610E: Der Server erfordert SSL-Integrität, aber der Client
unterstützt diese Option nicht.
FEHLER 3: CWWSA0612E: Der Client erfordert eine Clientauthentifizierung (z. B.
Benutzer-ID/Kennwort oder Token), aber der Server unterstützt diese Option nicht.
minor code: 0
completed: No at
com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey
(SecurityConnectionInterceptor.java:1770)
Im Allgemeinen müssen Sie zur Behebung des Fehlers die Sicherheitskonfiguration des Clients oder des Servers ändern. Wenn Sie feststellen möchten, welche Konfigurationseinstellung betroffen ist, lesen
Sie den Text, der nach der CWWSA-Fehlernachricht folgt. Ausführliche Erläuterungen und Anweisungen finden Sie in der Nachrichtenreferenz zur
Fehlernachricht. Wählen Sie dazu die Ansicht Referenz des Information Centers aus
und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Im Fall von Fehler 1 erfordert der Client SSL-Vertraulichkeit, der Server unterstützt die SSL-Vertraulichkeit jedoch nicht. Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Ändern Sie die Einstellungen des Servers so, dass er die SSL-Vertraulichkeit unterstützt, oder ändern Sie die Einstellungen des Clients so, dass er die SSL-Vertraulichkeit nicht mehr erfordert.
- Im Fall von Fehler 2 erfordert der Server die SSL-Integrität, aber der Client unterstützt die SSL-Integrität nicht. Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Ändern Sie die Einstellungen des Servers so, dass er die SSL-Vertraulichkeit unterstützt, oder ändern Sie die Einstellungen des Clients so, dass er die SSL-Vertraulichkeit nicht mehr erfordert.
- Im Fall von Fehler 3 schließlich erfordert der Client die Clientauthentifizierung über Benutzer-ID/Kennwort, aber der Server unterstützt diesen Typ der Clientauthentifizierung nicht. Auch in diesem Fall muss entweder die Clientkonfiguration oder die Serverkonfiguration geändert werden. Zum Ändern der Clientkonfiguration müssen Sie die Datei SAS.CLIENT.PROPS so konfigurieren, dass Sie einen reinen Client erhalten, oder die Ausgangskonfiguration des Servers in der Administrationskonsole für die Sicherheit ändern. Um die Konfiguration des Zielservers zu ändern, müssen Sie die Eingangskonfiguration in der Administrationskonsole für die Sicherheit ändern.
Wenn der Server beim Versuch, eine Clientanforderung zu bearbeiten, eine Fehlerbedingung wie org.omg.CORBA.INITIALIZE: JSAS0477W: Abweichung bei den Sicherheitskonfigurationen von Client und Server: empfängt, bedeutet das, dass die Sicherheitskonfigurationen zwischen dem Client und dem Server nicht übereinstimmen. Die Schritte, die zur Auflösung des Fehlers erforderlich sind, stimmen mit den oben
beschriebenen Schritten für die Ausnahmen vom Typ JSAS1477W überein.
Der Client wird nicht zur Eingabe von Daten aufgefordert, wenn er auf eine gesicherte Enterprise-Bean zugreift
Auch wenn die Sicherheitskomponente scheinbar aktiviert und eine bestimmte Enterprise-Bean geschützt ist, kann der Fall eintreten, dass der Client die ferne Methode ohne Systemanfragen ausführt. Wenn die ferne Methode geschützt wird, erhalten Sie einen Berechtigungsfehler. Ist dies nicht der Fall, führen Sie die Methode als nicht authentifizierter Benutzer aus.
- Für den Server, mit dem Sie kommunizieren, wurde die Sicherheitskomponente nicht aktiviert. Vergewissern Sie sich beim Administrator von WebSphere Application Server, dass die Sicherheitskomponente des Servers aktiviert ist. Der Zugriff auf die Sicherheitseinstellungen erfolgt über den Abschnitt Sicherheit der Administrationskonsole.
- Für den Client wurde die Sicherheitskomponente in der Datei sas.client.props nicht aktiviert. Editieren Sie die Datei sas.client.props, um sicherzustellen, dass die Eigenschaft "com.ibm.CORBA.securityEnabled" auf true gesetzt ist.
- Für den Client wurde kein ConfigURL angegeben. Vergewissern Sie sich, dass die Eigenschaft "com.ibm.CORBA.ConfigURL" angegeben ist, indem Sie in der Befehlszeile des Java-Clients den Parameter "-D" verwenden.
- Der angegebene ConfigURL hat eine ungültige URL-Syntax oder die Datei
sas.client.props, auf die er verweist, kann nicht ermittelt werden. Vergewissern Sie sich, dass die
Eigenschaft "com.ibm.CORBA.ConfigURL"
gültig ist. Prüfen Sie, ob die Java-Dokumentation eine Beschreibung der Formatierungsregeln für URLs enthält. Prüfen Sie auch,
ob die Datei unter dem angegebenen Pfad angegeben ist.
Ein Beispiel für eine gültige Eigenschaft ist C:/WebSphere/AppServer/properties/sas.client.props.
Die Clientkonfiguration unterstützt die Clientauthentifizierung über die Nachrichtenschicht (Benutzer-ID/Kennwort) nicht. Vergewissern Sie sich, dass in der Datei sas.client.props eines der folgenden Eigenschaften auf true gesetzt ist:
- com.ibm.CSI.performClientAuthenticationSupported=true
- com.ibm.CSI.performClientAuthenticationRequired=true
Die Serverkonfiguration unterstützt keine Clientauthentifizierung auf Nachrichtenebene, die sich aus einer Benutzer-ID und einem Kennwort zusammensetzt. Vergewissern Sie sich beim Administrator von WebSphere Application Server, dass die Authentifizierung über Benutzer-ID und Kennwort für die Eingangskonfiguration des Servers im Sicherheitscenter des Verwaltungstools der Administrationskonsole angegeben ist.
Nach dem Aktivieren der Sicherheitskomponente kann ein Anwendungsserver, Knotenmanager oder Knoten nicht gestoppt werden
Wenn Sie zum Stoppen der Prozesse von WebSphere Application Server Befehlszeilenprogramme verwenden, müssen Sie nach dem Aktivieren der Sicherheit zusätzliche Parameter anwenden, um die Authentifizierungs- und Berechtigungsdaten bereitzustellen.
Zeigen Sie mit dem Befehl
./stopServer -help die zu verwendenden Parameter an.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- ./stopServer serverName -username Name -password Kennwort
- ./stopNode -username Name -password Kennwort
- ./stopManager -username Name -password Kennwort
Wenn Sie die Windows-Anzeige "Dienste" oder den Befehl "net stop" zum Stoppen von WebSphere Application Server-Prozessen verwenden und der Service nicht gestoppt werden kann, müssen
Sie den vorhandenen Application Server-Dienst mit zusätzlichen Stoppargumenten aktualisieren. Möglicherweise müssen Sie den Serverprozess über den Task-Manager beenden, bevor Sie den Service aktualisieren. Verwenden Sie die Parameter -stopArgs und -encodeParams, um den Dienst gemäß
der Beschreibung im Beispiel "Vorhandenen Application-Server-Dienst aktualisieren"
im Artikel Befehl WASService zu aktualisieren.
.
Nach dem Aktivieren von SSO (Single Sign-On) kann die Anmeldung an der Administrationskonsole nicht mehr durchgeführt werden
Dieser Fehler tritt auf, wenn SSO (Single Sign-on) aktiviert ist und Sie versuchen, mit dem Kurznamen des Servers auf die Administrationskonsole zuzugreifen, z. B. http://myserver:Portnummer/ibm/console. Der Server akzeptiert Ihre Benutzer-ID und Ihr Kennwort, gibt jedoch die Anmeldeseite und nicht die Administrationskonsole zurück.
Möchten Sie diesen Fehler beheben, verwenden Sie den vollständig qualifizierten Hostnamen des Servers, z. B. http://meinserver.meinnetzwerk.meinefirma.com:9060/ibm/console.
SECJ0306E: Es wurde kein empfangener oder Aufrufberechtigungsnachweis im Thread gefunden.
Die folgende Nachricht wird angezeigt, wenn einer oder mehrere Knoten in der Zelle während der Konfiguration nicht synchronisiert wurden:SECJ0306E: Es wurde kein empfangener oder Aufrufberechtigungsnachweis im Thread gefunden. Die
rollebasierte Berechtigungsprüfung hat demzufolge nicht die Zugriffs-ID des zu prüfenden aufrufenden Programms. Die Parameter sind Zugriffsprüfmethode getServerConfig für Ressource FileTransferServer und Modul FileTransferServer. Der Stack-Trace ist: java.lang.Exception: Aufruf und empfangene Berechtigungsnachweise sind beide null.
Stellen Sie sicher, dass alle Knoten synchronisiert sind, und starten Sie anschließend den Deployment Manager erneut.
Ein NameNotFoundException-Fehler tritt auf, wenn zum ersten Mal eine Verbindung zu den eingebundenen Repositorys hergestellt wird
Wenn der Server versucht, eine indirekte Lookup-Operation für den Namen
java:comp/env/ds/wimDS auszuführen und zum ersten Mal eine EJB-Verbindung zu den eingebundenen Repositorys herstellt, wird die folgende Fehlernachricht
in der Datei SystemOut.log angezeigt:
Wenn der Server versucht, eine indirekte Lookup-Operation für den Namen
java:comp/env/ds/wimDS auszuführen und zum ersten Mal eine EJB-Verbindung zu den eingebundenen Repositorys herstellt, wird die folgende Fehlernachricht
in der Ausgabe des entsprechenden Jobprotokolls angezeigt:
NMSV0612W:
Ausnahme vom Typ NameNotFoundException
![[z/OS]](../images/ngzos.gif)
Der NameNotFoundException-Fehler wird von der Referenzbindungsdefinition für den JNDI-Namen (Java Naming and Directory Interface) jdbc/wimDS in der Datei ibm-ejb-jar-bnd.xmi ausgelöst. Sie können diese Warnung ignorieren. Bei der Konfiguration des wimDS-Datenbankrepository wird diese Nachricht nicht mehr angezeigt.

Ein Modul von Java EE Version 5 oder einer höheren Version kann jedoch in einer Anwendung, die Dateien einer älteren Java EE-Version als Version 5 enthält, koexistieren.
Die Dateien ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi und ibm-portlet-ext.xmi können die Dateierweiterung ".xmi" weiterhin verwenden.
sptcfg