Bekannte Probleme und Einschränkungen für die Laufzeitumgebung
Bei der Arbeit mit der Liberty-Laufzeitumgebung sind einige bekannte Einschränkungen zu beachten.

Weitere Informationen finden Sie unter Bekannte Einschränkungen für Develper Tools.
Releaseinformationen
Wenn es keine Releaseinformationen zum Betriebssystem gibt, erscheint beim Klicken auf den Link eine Seite, in der Sie darauf hingewiesen werden, dass keine Releaseinformationen gefunden wurden.
Liste bekannter Probleme und Einschränkungen:
- Allgemeine Einschränkungen:
- Unterstützte Java-Mindestversionen
- Pfad und Name des Installationsverzeichnisses dürfen keine Nicht-ASCII-Zeichen enthalten
- Änderung der JDBC-Datenquelle während der Ausführung kann JPA-Fehler verursachen
- Eine Anwendung, die darauf angewiesen ist, dass ein Ergebnis von getRealPath zurückgegeben wird, muss als erweiterte Anwendung, nicht als WAR-Datei, implementiert werden
- WebSphere Application Server Traditional-Scripts können mit Liberty nicht ausgeführt werden
- Einschränkungen für Dateigruppen
Wenn Sie die Veröffentlichung einer gemeinsam genutzten Bibliothek rückgängig machen, kann diese erst nach dem Stoppen des Servers gelöscht werden
z/OS APAR OA37620 ist erforderlich, um das Server-Tracing für eine bestimmte Tracegruppe zu aktivieren
- Einschränkungen für java:global-Lookups
- Anwendungen werden in einem integrierten Liberty-Server nicht gestartet
- Einschränkungen des WebSphere MQ-Ressourcenadapters und der generischen JCA-Unterstützung
- Versionssteuerung für Anwendungen im Verzeichnis dropins ist nicht möglich
- Features für Verbünde, dynamisches Routing und Skalierung können nicht zusammen mit dem Feature cdi-1.2 verwendet werden
- Anwendungen, die Sitzungen gemeinsam nutzen, müssen Sitzungsobjekte in gemeinsam genutzten Bibliotheken speichern
- Sitzungspersistenz konfigurieren
- Portierte, lokal ausgeführte JMS-Sitzungen funktionieren nicht in Liberty
- Liberty-Verwendung von IBM MQ-Messaging
Liberty-Anwendungen, die in IBM Cloud Private ausgeführt werden
Einschränkungen für die JSON-Protokollierung
- Spezifische Einschränkungen für Liberty-Features:
- Einschränkungen für das Feature Admin Center
- Einschränkungen für das Feature "appClient-1.0"
- Einschränkungen für das Feature appSecurity-2.0
- Einschränkungen für das Feature "beanValidation"
- Einschränkungen für das Feature "collectiveController-1.0"
- Einschränkungen für das Feature "concurrent-1.0"
- Einschränkungen für das Feature "Dynamischer Cache"
- Einschränkungen für EJB-Features (Enterprise JavaBeans)
- Einschränkungen für das Feature "j2eeManagement-1.1"
- Einschränkungen für das Feature "jacc-1.5"
- Einschränkungen für das Feature "jaxb-2.2"
- Einschränkungen für das Feature "jaxws-2.2"
- Einschränkungen für das Feature "jpa-2.1"
- Einschränkungen für das Feature "jsf-2.2"
- Einschränkungen für das Feature "jsp-2.2"
- Einschränkungen für das Feature "logstashCollector-1.0"
- Einschränkungen für das Feature "monitor-1.0"
Einschränkungen für das Feature "openapi-3.0"
- Einschränkungen für das Feature "requestTiming-1.0"
- Einschränkungen für das Feature "restConnector-1.0"
- Einschränkungen für das Feature "scim-1.0"
- Einschränkungen für "socialLogin-1.0"
- Einschränkungen für das Feature "sipServlet-1.1"
- Einschränkungen für das Feature "wmqJmsClient-1.1"
- Einschränkungen für das Feature wmqJmsClient-2.0
- Änderung der Eigenschaften "dataSource", "jdbcDriver", "connectionManager" und der JDBC-Anbietereigenschaften während der Ausführung kann JPA-Fehler verursachen
Unterstützte Java-Mindestversionen
![[17.0.0.3 und höher]](../ng_v17003plus.gif)
- Java SE 6-Laufzeitumgebung
Wichtig: Die Unterstützung für die Verwendung von Java SE 6 mit WebSphere Liberty wurde im September 2017 beendet. Der Liberty-Kernel wurde für Version 17.0.0.3 erneut kompiliert. Ab Version 17.0.0.3 kann der Liberty-Kernel nicht mehr mit Java SE 6 ausgeführt werden. Wenn Sie nach dem Ende des Unterstützungszeitraums Java SE 6 in Vorgängerversionen weiterhin verwenden, setzen Sie Ihre Umgebung möglicherweise Sicherheitsrisiken aus.
Java SE 8 ist das empfohlene Java SDK, da es die aktuellsten Features und Sicherheitsaktualisierungen beinhaltet. Alternativ zur Installation von Java SE 8 können Sie eine andere, unterstützt Java SDK-Version installieren.
- Java SE 7-Laufzeitumgebung
- Für das Java-SDK von IBM ist die unterstützte Mindestversion IBM Runtime Environment, Java Technology Edition 7.0.4.1. Für das JDK von Oracle unter Windows und Linux ist die unterstützte Mindestversion Java SDK/JRE/JDK 7.0.17. Für das JDK von Oracle unter Mac OS X ist die unterstützte Mindestversion Java SDK/JRE/JDK 7.0 Update 15.
- Wichtig: Ab Fixpack 19.0.0.3 wird der Liberty-Kernel nicht mehr mit Java SE 7 ausgeführt. Weitere Informationen finden Sie unter Entfernungsmitteilungen.
- Java SE 8-Laufzeitumgebung
- Für das Java-SDK von IBM ist die unterstützte Mindestversion IBM SDK Java Technology Edition Version 8. Für das JDK von Oracle ist die unterstützte Mindestversion Java 8 Update 25.
Auf verteilten
Plattformen wird 32-Bit- oder
64-Bit-Java unterstützt.
Auf der Plattform
z/OS wird nur 64-Bit-Java unterstützt.
Für Windows- und Linux-Systeme
können Sie das JDK von Oracle oder das Java SDK von IBM verwenden. Wenn Sie Anwendungen
unter Windows oder Linux entwickeln
und vorhaben, diese Anwendungen in einem Server zu implementieren, der in
WebSphere Application Server Traditional ausgeführt wird,
verwenden Sie das Java SDK von IBM. Für HP-Systeme und Mac OS müssen Sie das JDK von Oracle verwenden.
Verwenden Sie für z/OS-Systeme das Java-SDK von IBM.
Für IBM i V7R1 ist die JDK-Mindestversion IBM Java SE 7.0 32-bit JVM (5761JV1 option 14) oder IBM Java SE 7.0 64-bit JVM (5761JV1 option 15).Für IBM i V7R2 und V7R3 ist die JDK-Mindestversion IBM Fü
Java SE 7.0 32-bit JVM (5770JV1 option 14) oder IBM
Java SE 7.0 64-bit JVM (5770JV1 option 15).
Pfad und Name des Installationsverzeichnisses dürfen keine Nicht-ASCII-Zeichen enthalten
Neuere JVMs bieten keine vollständige Unterstützung für die Verwendung von Nicht-ASCII-Zeichen in den Befehlen -jar und -javaagent. Verwenden Sie in den Namen und Pfaden Ihrer Installationsverzeichnisse nur ASCII-Zeichen.
Änderung der JDBC-Datenquelle während der Ausführung kann JPA-Fehler verursachen
Falls der Typ des Datenbankwörterverzeichnisses nicht mit Eigenschaften angegeben wird, wird er von OpenJPA erkannt und ermittelt, wenn der erste Entitätsmanager erstellt und die Datenbankverbindung hergestellt wird. Dieser Typ des Datenbankwörterverzeichnisses wird für alle Entitätsmanager verwendet, die nachfolgend erstellt werden. Wird die JDBC-Datenquelle geändert, während die Anwendung ausgeführt wird, kann die Entitätsmanager-Factory diese Änderung nicht erkennen und sie verwendet weiterhin das alte Wörterverzeichnis für Operationen, die für die neue Datenquelle ausgeführt werden. Dies kann zu Fehlern führen, falls eine Umstellung auf die Datenbank eines anderen Anbieters vorgenommen wird.
Wenn Sie eine Umstellung auf die Datenbank eines anderen Anbieters vornehmen, starten Sie die Anwendung erneut.
Änderung der Eigenschaften "dataSource", "jdbcDriver", "connectionManager" und der JDBC-Anbietereigenschaften während der Ausführung kann JPA-Fehler verursachen
Wenn Sie die Konfiguration der Eigenschaften dataSource, jdbcDriver, connectionManager oder der Listen mit JDBC-Anbietereigenschaften (z. B. properties.db2.jcc oder properties.oracle) ändern, während der Server ausgeführt wird, können Fehler des Typs J2CA8040E angezeigt werden. Diese Fehler weisen darauf hin, dass es nicht möglich ist, einem einzigen connectionManager mehrere dataSource-Elemente zuzuordnen. Diese Fehler werden auch dann generiert, wenn dem connectionManager nur ein einziges dataSource-Element in der Konfiguration zugeordnet ist.
Wenn Sie Änderungen an der Konfiguration einer dieser JDBC-Ressourcen vornehmen, starten Sie den Server erneut.
Eine Anwendung, die darauf angewiesen ist, dass ein Ergebnis von getRealPath zurückgegeben wird, muss als erweiterte Anwendung, nicht als WAR-Datei, implementiert werden
Die Java EE-Spezifikation legt fest, dass die Methode getRealPath() den Wert null zurückgibt, wenn der Inhalt aus einer WAR-Datei (Webarchiv) bereitgestellt wird. Wenn Sie eine WAR-Datei in Liberty implementieren, wird die Archivdatei nicht automatisch in eine Verzeichnisstruktur gepackt. Daher kann die Anwendung möglicherweise nicht gestartet werden. Wenn Ihre Anwendung erwartet, dass ein Ergebnis von getRealPath() zurückgegeben wird, müssen Sie die Anwendung als erweiterte Webanwendung, nicht als WAR-Datei, implementieren. Beispielsweise können Sie die WAR-Datei manuell entpacken und die erweiterte Anwendung in das Verzeichnis dropins kopieren.
WebSphere Application Server Traditional-Scripts können mit Liberty nicht ausgeführt werden
Keines der Scripts im Verzeichnis bin von WebSphere Application Server Traditional kann für die Verwaltung von Liberty verwendet werden.
Einschränkungen für Dateigruppen
- Dateigruppen können die Unterverzeichnisse des Basisverzeichnisses nicht rekursiv durchsuchen. Beispielsweise
werden die folgenden Anweisungen nicht unterstützt:
<fileset id="testFileset" dir="\temp" includes="**\a.jar"/> <fileset id="testFileset" dir="\temp" includes="a\a.jar"/> <fileset id="testFileset" dir="\temp" includes="*\a.jar"/> <fileset id="testFileset" dir="\temp" includes="a\b\a.jar"/>

Wenn Sie die Veröffentlichung einer gemeinsam genutzten Bibliothek rückgängig machen, kann diese erst nach dem Stoppen des Servers gelöscht werden
Wenn Sie die Veröffentlichung einer gemeinsam genutzten Bibliothek auf einem Server rückgängig machen, wird die JAR-Datei der Bibliothek nicht sofort vom Server freigegeben. Das Betriebssystem weiß daher nicht, dass die Datei nicht mehr verwendet wird, und lässt das Löschen der Datei nicht zu. Wenn Sie den Server das nächste Mal stoppen, wird die JAR-Datei der Bibliothek freigegeben, und Sie können die Datei löschen.

z/OS APAR OA37620 ist erforderlich, um das Server-Tracing für eine bestimmte Tracegruppe zu aktivieren
Wenn Sie einzelne Tracegruppen verfolgen möchten, müssen Sie z/OS APAR OA37620 anwenden. Wird das Tracing für Liberty auf der z/OS-Plattform aktiviert, verwenden Sie die Paket-/Klassensyntax (d. h. com.ibm.ws.*=all), sofern Sie keine anderen Anweisungen vom IBM Support erhalten.
Einschränkungen für java:global-Lookups
Ressourcen, die in Anwendungen mit java:global-Lookups definiert sind, können verwendet werden, um auf Namen zuzugreifen, die von im aktuellen Server implementierten Anwendungen deklariert wurden.
Anwendungen werden in einem integrierten Liberty-Server nicht gestartet
Vergewissern Sie sich, dass der Java-Prozess, der den eingebetteten Liberty-Server startet, mit dem JVM-Argument -javaagent, das auf Liberty-Installationsverzeichnis/bin/tools/ws-javaagent.jar verweist, gestartet wurde. Wenn das JVM-Argument -javaagent nicht verwendet wird, wird die Serverlaufzeit gestartet, aber der Start von Anwendungen schlägt ohne offensichtliche Ausnahmen fehl.
Einschränkungen des WebSphere MQ-Ressourcenadapters und der generischen JCA-Unterstützung
Der WebSphere® MQ-Ressourcenadapter kann in WebSphere Application Server Liberty verwendet werden, indem das Feature wmqJmsClient-1.1 oder das Feature wmqJmsClient-2.0 oder die generische JCA-Unterstützung verwendet wird.
Sie können den WebSphere MQ-Ressourcenadapter der Version 7.5 mit Liberty Version 8.5.5 und höher verwenden. Wenn Sie den WebSphere MQ-Ressourcenadapter der Version 8.0 verwenden möchten, der auf dem JMS 2.0-Ressourcenadapter basiert, müssen Sie sicherstellen, dass Sie die aktuellste mit dem JMS 2.0-Ressourcenadapter kompatible Version von Liberty verwenden.
- In Liberty Version 8.5.5.2 muss das Feature wmqJmsClient-1.1 mit einem IBM MQ-Ressourcenadapter der Version 7.5.0.5 oder höher verwendet werden.
- In Liberty Version 8.5.5.6 muss das Feature wmqJmsClient-2.0 mit einem IBM MQ-Ressourcenadapter der Version 8.0.0.3 oder höher verwendet werden.
Weitere Informationen zur Versionskompatibilität zwischen dem WebSphere MQ-Ressourcenadapter und Liberty finden Sie unter Reference to obtain the WebSphere MQ resource adapter.
- Zum Ausführen des IBM® WebSphere MQ-Ressourcenadapters unter z/OS müssen Sie das Feature wmqJmsClient-1.1 oder wmqJmsClient-2.0 verwenden.
- Die Traceerstellung und die Protokollierung sind nicht über JCA im Liberty-Tracesystem integriert. Der Trace wird in eine separate Datei geschrieben und muss durch Festlegen der Systemeigenschaften aktiviert werden. Zum Aktivieren der Traceerstellung gehen Sie genauso vor wie zum Konfigurieren der WebSphere MQ-Klassen für die JMS-Tracefunktion für eine Java-Standardumgebung. Weitere Informationen finden Sie unter Java Standard Environment Trace stanza.
- Die IBM MQ-Klassen für Java werden nicht in Liberty unterstützt. Sie dürfen weder mit dem IBM MQ Liberty-Messaging-Feature noch mit der generischen JCA-Unterstützung verwendet werden. Weitere Informationen finden Sie unter Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.
Versionssteuerung für Anwendungen im Verzeichnis dropins ist nicht möglich
Bei Anwendungen im Verzeichnis dropins werden der Dateiname und die Dateierweiterung vom Anwendungsmonitor verwendet, um den Typ der Anwendung zu ermitteln und die Anwendungs-ID und den Anwendungsnamen zu generieren. Es ist deswegen nicht möglich, die Versionsnummer für die Anwendung durch die Verwendung des Dateinamens oder der Dateierweiterung anzugeben. Es wird empfohlen, das Verzeichnis dropins in einer Produktionsumgebung nicht zu verwenden.
Features für Verbünde, dynamisches Routing und Skalierung können nicht zusammen mit dem Feature cdi-1.2 verwendet werden
Verwenden Sie die Features collectiveController-1.0, collectiveMember-1.0, clusterMember-1.0, dynamicRouting-1.0, scalingController-1.0 und scalingMember-1.0 nicht zusammen mikt dem Feature cdi-1.2 (Contexts and Dependency Injection 1.2).
Anwendungen, die Sitzungen gemeinsam nutzen, müssen Sitzungsobjekte in gemeinsam genutzten Bibliotheken speichern
Wenn Sie die Anwendungserweiterung "shared-session-context" oder <shared-session-context value="true"/> in der Datei ibm-application-ext.xml verwenden, müssen alle in der Sitzung gespeicherten Objekte in den gemeinsam genutzten Bibliotheken, die der Anwendung zugeordnet sind, verfügbar sein, damit die Sitzung ungültig gemacht werden kann.
Sitzungspersistenz konfigurieren
Es gibt nur eine einzige server.xml-Datei für jeden Server. Es gibt keine server.xml-Datei für jede EAR- oder WAR-Datei. Sie legen die Sitzungspersistenz in einer Datenbank fest, indem Sie Folgendes hinzufügen:
<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
In Liberty gilt diese Einstellung für die Datenbank für alle EAR- und WAR-Dateien. Es ist nicht möglich, einige Datenbanken mit Sitzungspersistenz und andere ohne Sitzungspersistenz zu konfigurieren.
Portierte, lokal ausgeführte JMS-Sitzungen funktionieren nicht in Liberty
In WebSphere Application Server Traditional können Sie Anwendungen entwickeln, die die Vorteile lokal ausgeführter JMS-Sitzungen nutzen. Wenn Sie diese Anwendungen in Liberty portieren, verhalten sich diese Anwendungen anders oder funktionieren überhaupt nicht.
Auch wenn WebSphere Application Server Traditional lokal ausgeführte JMS-Sitzungen zulässt, ist das Portieren einer lokal ausgeführten WebSphere Application Server Traditional-JMS-Sitzung in Liberty nicht zulässig.
Liberty-Verwendung von IBM MQ-Messaging
Wenn Liberty IBM MQ als Messaging-Provider verwendet, unterscheiden sich die Wiederverwendungskriterien für eine freie Verbindung des JMS-Verbindungspools von denen in WebSphere Application Server Traditional. Die Wiederverwendungsgeschwindigkeit ist insbesondere für Liberty sehr viel geringer als die von WebSphere Application Server Traditional, wenn eine JMS-Anwendung Containerauthentifizierung für eine Verbindungsfactory und mehrere authentifizierte Benutzer denselben Verbindungspool verwenden. Die Wiederverwendungsgeschwindigkeit von Liberty ist niedriger, da die freie Verbindung, die von einem authentifizierten Benutzer erstellt wird, nicht von anderen authentifizierten Benutzern in Liberty wiederverwendet werden kann und daher dazu führen kann, dass Verbindungen häufig erneut hergestellt werden müssen. Sie können Anwendungsauthentifizierung mit den Eigenschaften username und password für properties.wmqJms verwenden, wenn die Wiederverwendungsgeschwindigkeit von Liberty nicht den Leistungsanforderungen entspricht.
![[17.0.0.3 und höher]](../ng_v17003plus.gif)
Liberty-Anwendungen, die in IBM Cloud Private ausgeführt werden
- Automatisches Skalieren basiert nur auf der CPU-Auslastung, nicht auf angepassten Metriken.
- Ingress unterstützt nur Basiskonfiguration und Annotationen, wie z. B. Einzelstammkontext.
- Es treten möglicherweise Probleme beim Zugriff auf Anwendungen auf, die Ingress mit dem HTTP-Protokoll verwenden. Wenn Sie auf eine Anwendung über http://Proxy-Host/ zugreifen, werden Sie an den Port 80 umgeleitet. Dies ist nicht richtig, daher kann auf die Anwendung nicht zugegriffen werden. Entfernen Sie Port 80 aus der URL, um das Problem zu beheben.
- Momentan unterstützt das Liberty-Helmdiagramm nur die Persistenz von Transaktionsprotokollen für ein einzelnes Replikat.
![[18.0.0.1 und höher]](../ng_v18001plus.gif)
Einschränkungen für die JSON-Protokollierung
- Wenn die Binärprotokollierung konfiguriert ist, behalten Protokolleinträge, die in der Konsole ausgegeben werden, das Basisformat auch dann bei, wenn die JSON-Protokollierung aktiviert ist.
- Wenn die JSON-Protokollierung unter z/OS aktiviert ist, fehlen möglicherweise einige Nachrichten im Serverstartzeitraum.
- Wenn die JSON-Protokollierung aktiviert ist, werden "Throwables", die in der Datei System.out/err protokolliert werden, nicht mit dem Hinweis [internal classes] abgeschnitten.
Einschränkungen für das Feature Admin Center
![[16.0.0.4 und höher]](../ng_v16004plus.gif)
- Jobprotokolle von fernen Maschinen können nur angezeigt werden, wenn jeder ferne Server mit Stapeljobs oder Jobprotokollen eine CORS-Konfiguration hat. Informationen hierzu finden Sie unter Java-Stapeljobs im Admin Center anzeigen.
- Wenn Instanzprotokolle angezeigt werden, müssen Sie mit einem Fehler rechnen, wenn sich die Ausführungen über mehrere Hosts hinweg erstrecken.
- Das Java-Batch-Tool setzt die Verwendung einer persistenten Datenbank mit dem Feature batchManagement-1.0 voraus.
Einschränkungen für das Feature "appClient-1.0"
- Das Feature unterstützt keine Java EE-Anwendungsclients und kann nur eigenständige Clientprogramme starten.
Einschränkungen für das Feature appSecurity-2.0
- Für EJB-Anwendungen wird die run-as-mode-Einstellung SYSTEM_IDENTITY in den Erweiterungseinstellungen der Datei ibm-ejb-jar-ext.xml nicht unterstützt.
- Die API getCallerIdentity wird für Singleton-Session-Beans nicht unterstützt.
- Rollennamen können von den APIs HttpServletRequest.isUserInRole und EJBContext.isCallerInRole oder von Elementen im Implementierungsdeskriptor referenziert werden, ohne dass zuerst die Rollennamen mit der Annotation @DeclareRoles oder dem Element <security-role/> im Implementierungsdeskriptor deklariert werden müssen. Rollen müssen aber vor der Verwendung in WebSphere Application Server Traditional deklariert werden.
Einschränkungen für das Feature "beanValidation"
- Es gibt keine Unterstützung für die Beanvalidierung in OSGi-Anwendungen.
- Es gibt keine Unterstützung für die Beanvalidierung in OSGi-Anwendungen.
- Anwendungen, die eine angepasste ConstraintValidatorFactory-Implementierung in einer Datei des Typs validation.xml mit dem Feature beanValidation-1.0 bereitstellen, können nicht mit der Bean Validation 1.1 API kompiliert werden.
- Wenn keine Datei validation.xml im zugeordneten Modul vorhanden ist,
kann es nur eine einzige Datei validation.xml geben und die Eigenschaft
com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp muss in einer der beiden Dateien auf
false gesetzt werden:
- jvm.options
-Dcom.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false
- bootstrap.properties
com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false
- jvm.options
Einschränkungen für das Feature "collectiveController-1.0"
Wenn Sie einen Verbundcontroller-Server starten und dann Ihre IP-Konfiguration ändern, funktioniert der Controller nicht mehr ordnungsgemäß.
Einschränkungen für das Feature "concurrent-1.0"
Für das Feature "concurrent-1.0" gelten die folgenden Einschränkungen:
Bei einem Threadkontext des Typs securityContext werden angepasste Informationen im Subjekt, die nicht mit einem JAAS-Anmeldemodul hinzugefügt wurden, nicht weitergegeben. Wenn beispielsweise das Subjekt des Übergebenden einen angepassten Principal enthält, der von einem TAI hinzugefügt wurde, enthält das weitergegebene Subjekt diesen angepassten Principal nicht.
Einschränkungen für das Feature "Dynamischer Cache"
- Die Cachereplikation wird nicht unterstützt.
- Für wahlfreie oder größenbasierte Bereinigungsverfahren wird nur der Caching-Modus mit Hochleistungsdatenträger unterstützt.
- In der Datei cachespec.xml werden das client- und serverseitige Caching von Web-Services sowie das Portlet-Caching nicht unterstützt.
- Das Servlet-Caching für SingleThreadModel-Servlets wird nicht unterstützt.
- Die Definition der Cachekonfiguration mit Eigenschaftendateien wird für JAR-Dateien, die nur EJBs (Enterprise JavaBeans) enthalten, nicht unterstützt.
- Die Größenbeschränkung des Heapspeichercaches funktioniert nur für 32-Bit-JVMs (Java Virtual Machine).
Einschränkungen für EJB-Features (Enterprise JavaBeans)
- EJB-Module einer älteren Version als Version 3.0 werden nicht unterstützt, wenn ausschließlich die EJB Lite-Features verwendet werden, weil keine EJB-Home-Objekte in EJB Lite enthalten sind. Diese Einschränkung bedeutet auch, dass Bindungen und Erweiterungen, die das Format .xmi und nicht .xml verwenden, nicht unterstützt werden.
- Session-Beans sind nicht an den Namespace ejblocal gebunden, d. h., in JNDI-Suchen und für ejb-ref-Bindungsnamen müssen die Namen java:global, java:app oder java:module verwendet werden. simple-binding-name und Schnittstellenelemente vom Typ binding-name werden in Dateien vom Typ ibm-ejb-jar-bnd.xml ignoriert.
- Das Auslagerungsverzeichnis für Stateful Beans ist nicht konfigurierbar. Die Dateien werden im Arbeitsbereich des Servers inaktiviert.
Einschränkungen für das Feature "j2eeManagement-1.1"
Für das Feature j2eeManagement-1.1 gilt die folgende Einschränkung:
- Die Management-EJB-Methode getListenerRegistry() wird nicht unterstützt. Sie können keinen Listener für Ereignisbenachrichtigungen in einer Management-EJB-Komponente registrieren.
Einschränkungen für das Feature "jacc-1.5"
- Berechtigungsinformationen (die Benutzer- und Gruppenattribute des Berechtigungsattributs) in einer Datei des Typs ibm-application-bnd.xml oder ibm-application-bnd.xmi der EAR-Anwendungsdatei.
- Berechtigungsinformationen (die Attribute user, group und special-subject des Attributs security-role im Element application-bnd) in der Datei server.xml.
Einschränkungen für das Feature "jaxb-2.2"
- Wenn Ihre Anwendung JAXB-API-Klassen voraussetzt und bereits gestartet wurde und das Server-Feature jaxb-2.2 aktiviert werden soll, müssen Sie den Server mit der Option --clean erneut starten, damit Ihre Anwendung die JAXB-2.2-API- und -Implementierungsklassen, die vom Feature jaxb-2.2 bereitgestellt werden, aufrufen kann. Andernfalls könnte Ihre Anwendung weiterhin an die im Java SDK bereitgestellten JAXB-API- und -Implementierungsklassen gebunden werden.
- Wenn das Server-Feature jaxb-2.2 aktiviert wird und Sie Ihre eigenen JAXB-API- und -Implementierungsklassen in Ihrer Anwendung verwenden möchten, müssen Sie Ihre eigene JAXB-API und JAR-Implementierungsdateien in das Verzeichnis /WEB-INF/lib Ihrer Anwendung stellen und den Klassenlader Ihrer Anwendung so konfigurieren, dass das Delegierungsverhalten parentLast verwendet wird. Andernfalls werden die JAXB-API-Klassen und -Implementierungsklassen, die vom Feature jaxb-2.2 bereitgestellt werden, wirksam. Weitere Informationen zur Konfiguration des Klassenladerverhaltens für Ihre Anwendungen in Liberty finden Sie unter Bereitgestellte API mit einer alternativen Version überschreiben.
Einschränkungen für das Feature "jaxws-2.2"
- Wenn Ihre Anwendung eine eigene Kopie von CXF-JAR-Dateien als Anwendungsbibliotheken bereitstellt, z. B. im Verzeichnis WEB-INF/lib einer Webanwendung, können Sie das Feature jaxws-2.2 nicht in der Datei server.xml aktivieren.
- Da das Feature jaxws-2.2 vom Feature jaxb-2.2 abhängt, gelten die Einschränkungen des Features jaxb-2.2 auch für das Feature jaxws-2.2.
- Wenn Ihre Anwendung JAX-WS-API-Klassen voraussetzt und bereits gestartet wurde und das Server-Feature jaxws-2.2 aktiviert werden soll, müssen Sie den Server mit der Option "--clean" erneut starten, damit Ihre Anwendung die JAX-WS-2.2-API- und -Implementierungsklassen, die vom Feature jaxws-2.2 bereitgestellt werden, aufrufen kann. Andernfalls könnte Ihre Anwendung weiterhin an die im Java SDK bereitgestellten JAX-WS-API- und -Implementierungsklassen gebunden werden.
- Die Web-Service-Bindungsdatei für Liberty ist die Datei ibm-ws-bnd.xml. Die folgenden Web-Service-Bindungsdateien für
WebSphere
Application Server Traditional werden nicht unterstützt:
- ibm-webservices-ext.xmi
- ibm-webservices-bnd.xmi
- ibm-webservicesclient-ext.xmi
- ibm-webservicesclient-bnd.xmi
- ws-security.xml
- Die Apache-Axis2-Konfigurationen und -Klassen werden nicht unterstützt.
- Die Web-Service-Provider, die die Schnittstelle javax.xml.ws.Provider<OMElement> oder javax.xml.ws.Provider<String> implementieren, werden nicht unterstützt.
- Das Attribut content-id von MIME-Anhängen muss für Liberty in spitze Klammern gesetzt werden. Beispiel: <testID>.
- Die Option -inlineSchemas wird von dem mit Liberty bereitgestellten Tool wsgen nicht unterstützt.
- Aktivieren Sie MTOM, wenn Sie große Binärdaten mit JAX-WS-Web-Services übertragen möchten, um den OOM-Fehler (Out of Memory, Fehler aufgrund nicht ausreichender Speicherkapazität) zu vermeiden.
- Wenn sich der Service-Client und der Service-Provider bei Web-Service-Anwendungen nicht in derselben Anwendung befinden und die WSDL-Datei in der Service-Provider-Anwendung geändert wird, müssen Sie die Web-Service-Clientanwendung manuell erneut starten, um Cacheprobleme mit der WSDL-Definition zu vermeiden.
Einschränkungen für das Feature "jsf-2.2"
- Wenn Sie das Feature jsf-2.2 mit einer Datei faces-config.xml verwenden und Version 2.2. und einen Namespace angeben, tritt ein Fehler auf.
- Es treten Featurekonflikte auf, wenn Sie jsf-2.2 zusammen mit cdi-1.2, ejb-3.2 oder jpa-2.1 aktivieren.
Einschränkungen für das Feature "jsp-2.2"
- Die Konfigurationsoption useInMemory, mit der lediglich die übersetzte JSP-Datei im Hauptspeicher gespeichert werden kann, wird nicht unterstützt.
Einschränkungen für das Feature "jpa-2.1"
- Es kann kein alternativer JPA 2.1-Provider verwendet werden. Wenn Sie die Unterstützung für Version 2.1 benötigen, müssen Sie den integrierten Provider verwenden.
- In der Anwendung können keine EclipseLink-spezifischen Features und Annotationen verwendet werden. Sie können nur die javax.persistence-APIs verwenden.
Einschränkungen für das Feature "logstashCollector-1.0"
Die folgenden Einschränkungen gelten für das Feature logstashCollector-1.0:- Datenverlust – Einige in Liberty generierte Ereignisse werden möglicherweise nicht wie erwartet an Logstash weitergeleitet. Zum Datenverlust kann es in den folgenden Szenarien kommen:
- Der Liberty-Server wird vor dem Start des Logstash-Servers gestartet. Es wird empfohlen, den Logstash-Server vor dem Liberty-Server zu starten.
- Hohe Belastungen. Ereignisse werden möglicherweise gelöscht, wenn Ereignisse in Liberty schneller erstellt werden, als sie von der Liberty-Ereignispipeline, Logstash und anderen nachgeschalteten Konsumenten verarbeitet werden können. Liberty verwendet Puffer, um einen Datenverlust zu vermeiden, wenn die Ereigniserstellung kurzzeitig schneller als die Ereignisverarbeitung ist.
- Das Feature logstashCollector-1.0 wird getestet und ist mit Logstash Version 2.x und Logstash Version 5.x kompatibel.
Einschränkungen für das Feature "monitor-1.0"
- Wenn das Feature aus der Datei server.xml entfernt wird, müssen Sie den Server erneut starten, damit die JAX-WS-Anwendungen funktionieren.
![[17.0.0.3 und höher]](../ng_v17003plus.gif)
Einschränkungen für das Feature "openapi-3.0"
Für das Feature openapi-3.0 gelten folgende Einschränkungen:
- Im Gegensatz zu apiDiscovery-1.0 unterstützt openapi-3.0 momentan nicht das Feature Probieren Sie es aus!.
- Wenn Sie Ihre Dokumentation unter der URL http://Liberty-Host:HTTP-Port/api/docs, https://Liberty-Host:HTTPS-Port/api/docs oder https://Liberty-Hhost:HTTPS-Port/ibm/api/docs mit Microsoft Internet Explorer 11 anzeigen, wird ein YAML-Dokument zurückgegeben, das nicht ordnungsgemäß formatiert ist. Verwenden sie als Ausweichmaßnahme einen Browser wie Mozilla Firefox oder Google Chrome.
- openapi-3.0 unterstützt keine OASProvider-Konfigurationen für mehrere Sprachen. Geben Sie Provider an, die nur ein einziges Ergebnis zurückgeben.
- Es werden momentan nicht alle JAX-RS- und OpenAPI-Annotationen unterstützt.
- Wenn der Wert des Validierungsattributs geändert wird, während der Server aktiv ist, müssen zuvor geladene Anwendungen neu gestartet werden, damit die neue Validierungseinstellung für diese Anwendungen wirksam wird.
- Die folgenden Abschnitte des OpenAPI-Dokuments werden nicht validiert:
- component
- discriminator
- codieren
- extension
- header
- link
- Schema
- scopes
- xml
Einschränkungen für das Feature "requestTiming-1.0"
- Wenn das Feature requestTiming-1.0 aktiviert ist, führt dies zu einer Verringerung des maximalen Anwendungsdurchsatzes von 4 %, gemessen mit der Anwendung "DayTrader". Während die Auswirkungen auf die Anwendungen in etwa diesem Wert entsprechen, sollten Sie beachten, dass einige Leistungseinbußen bemerkbar sein können.
Einschränkungen für das Feature "restConnector-1.0"
Für das Feature restConnector-1.0 gilt die folgende Einschränkung:
- Benutzer, die das Feature restConnector-1.0 oder eines der Features verwenden, die restConnector-1.0 enthalten, wie z. B. collectiveMember-1.0 oder collectiveController-1.0, und die Anwendungen mit einer angepassten JAXRS 2.0-Laufzeitumgebungen ausführen möchten, müssen diesem Server das Feature jaxrs-2.0 hinzufügen.
Einschränkungen für das Feature "scim-1.0"
- Die members-Attribute werden beim Suchen nach groups nicht abgerufen.
- Die groups-Attribute von users werden beim Suchen nach users nicht abgerufen.
- Der kanonische Typ von direct/indirect kann für das groups-Attribut von users nicht gesetzt werden.
- Es kann nur ein einziges email-Attribut für den Benutzer mit kanonischem Typ (work) definiert werden.
- Es kann nur ein einziges ims-Attribut für den Benutzer mit kanonischem Typ (work) definiert werden.
- Erweiterte Schemaattribute von SCIM wie entitlements, roles und x509Certificates können nicht gesetzt oder zurückgegeben werden.
- Das Attribut userName kann nicht zusammen mit anderen Attributen in einem Filter verwendet werden.
- Für Benutzer in Basis- und SAF-Registrys können nur userName, displayName, id, schema, meta.location und groups gesetzt werden. userName und displayName haben denselben Wert.
- Das Auflisten und Abfragen funktioniert bei Basis- und SAF-Registrys nicht wie bei der Registery "ldapRegistry".
- Operatoren wie pr, gt, ge, lt, le, and, or und () funktionieren nicht für Basis- und SAF-Registrys. Außerdem darf bei Basis- und SAF-Registrys nur ein einziger Operator im Filter verwendet werden.
- Basis- und SAF-Registrys sind schreibgeschützt.
- Beim Erstellen von user kann das Attribut groups nicht gesetzt werden.
Einschränkungen für das Feature "sipServlet-1.1"
- SIP-Zähler für Performance Monitoring Infrastructure (PMI) werden nicht unterstützt.
- SIP-Digest-Authentifizierung und JSR 289 Section 17 (Abschnitt zur Sicherheit) werden nicht unterstützt.
- Clustering und SIP-Dialogpersistenz werden nicht unterstützt.
Einschränkungen für "socialLogin-1.0"
- Das Social-Media-Standardauswahlformular funktioniert möglicherweise beim Feature socialLogin-1.0 nicht ordnungsgemäß in Internet Explorer, wenn das Betriebssystem Windows Server 2012 verwendet wird. Wenn Sie einen Provider auswählen und das Formular übergeben wird, übergibt Internet Explorer möglicherweise den angezeigten Schaltflächentext als Standardwert anstelle des HTML-Werts, der für die Schaltfläche konfiguriert ist. Verwenden Sie einen anderen Web-Browser, um diese Einschränkung zu umgehen. Andere Browser als Internet Explorer funktionieren mit dem Standardauswahlformular ordnungsgemäß.
Einschränkungen für das Feature "wmqJmsClient-1.1"
- Die Variable PATH in den Windows-Umgebungsvariablen muss manuell so festgelegt werden, dass sie auf das IBM MQ-Installationsverzeichnis "bin" verweist. Diese Pfadvariable muss festgelegt werden, wenn die Anwendung den Verbindungsmodus BINDING verwendet.
- Die IBM MQ-Klassen für Java werden in Liberty nicht unterstützt. Sie dürfen weder mit dem IBM MQ-Liberty-Messaging-Feature noch mit der generischen JCA-Unterstützung verwendet werden. Weitere Informationen finden Sie unter Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.
- Der Transporttyp BINDINGS_THEN_CLIENT des IBM MQ-Ressourcenadapters wird für das Feature wmqJmsClient-1.1 nicht unterstützt.
- Advanced Messaging Security (AMS) wird für das Feature wmqJmsClient-1.1 nicht bereitgestellt.
Einschränkungen für das Feature wmqJmsClient-2.0
- Die Variable PATH in den Windows-Umgebungsvariablen muss manuell so festgelegt werden, dass sie auf das IBM MQ-Installationsverzeichnis "bin" verweist. Diese Pfadvariable muss festgelegt werden, wenn die Anwendung den Verbindungsmodus BINDING verwendet.
- Die IBM MQ-Klassen für Java werden in Liberty nicht unterstützt. Sie dürfen weder mit dem IBM MQ-Liberty-Messaging-Feature noch mit der generischen JCA-Unterstützung verwendet werden. Weitere Informationen finden Sie unter Using WebSphere MQ Java Interfaces in J2EE/JEE Environments.
- Der Transporttyp BINDINGS_THEN_CLIENT des IBM MQ-Ressourcenadapters wird für das Feature wmqJmsClient-2.0 nicht unterstützt.