Prise en charge des ressources externes Liberty
Les fonctions et ressources externes Liberty sont utilisables directement et vous pouvez compter sur leur présence dans les prochaines éditions. Les aspects internes ou marginaux peuvent en revanche changer en cas d'application d'un correctif de maintenance, ou à l'occasion d'une mise à niveau vers une édition ultérieure.
Quelles sont les ressources utilisables directement dans Liberty et sur lesquelles je peux compter dans la prochaine édition ?
Les ressources suivantes sont utilisables directement et seront toujours disponibles dans la prochaine édition :- Les interfaces de programmation d'application (API) et les
interfaces de programmation système (SPI) définies par le contenu des
fichiers JAR dans les répertoires
${wlp.install.dir}/dev.
- Le chargeur de classe de l'application voit les API fournies par les fonctions dans votre configuration de serveur. Les fonctions d'extension de produit voient toutes les API et toutes les SPI fournies par les fonctions dans votre configuration de serveur.
- Compilez votre code avec les fichiers JAR qui se trouvent dans les répertoires ${wlp.install.dir}/dev. Les fichiers JAR des répertoires ${wlp.install.dir}/dev sont fournis uniquement pour la compilation d'applications et de fonctions, ils ne sont pas pris en charge pour une exécution. N'utilisez pas ces fichiers JAR dans des applications, des bibliothèques ou des tests.
- La configuration de serveur, y compris les fonctions dont la visibilité est public ou protected. Les éléments de configuration et les fonctions publiques peuvent être spécifiés dans le fichier server.xml et fichiers inclus ; les fonctions protégées peuvent être incluses dans vos propres fonctions.
- Les commandes, les scripts et les archives dans le répertoire ${wlp.install.dir}/bin et ses sous-répertoires.
- Les utilitaires de client dans le répertoire ${wlp.install.dir}/clients et ses sous-répertoires.
Quels sont les éléments dont il vaut mieux ne pas être tributaire ?
- Noms des fichiers JAR des binaires du produit (par exemple, ceux du répertoire ${wlp.install.dir}/dev). Compilez votre code avec ces fichiers JAR en utilisant les outils ou l'option javac -extdirs.Si vous utilisez Apache Ant pour compiler votre code, utilisez des caractères génériques pour éviter les dépendances sur la version JAR spécifique ; par exemple :
Vous pouvez aussi utiliser la commande featureManager classpath pour générer un chemin d'accès aux classes pour un ensemble de fonctions spécifique. Pour plus d'informations, voir Commande featureManager.<fileset dir="${wlp.install.dir}/dev/api/spec" includes="com.ibm.ws.javaee.servlet.3.0_*.jar"/>
- Utilisation directe des fichiers binaires du produit dans le répertoire ${wlp.install.dir}/lib. Les seuls fichiers JAR qui peuvent être invoqués directement sont ceux qui se trouvent dans le répertoire ${wlp.install.dir}/bin/tools.
- Les messages générés par le serveur à l'exécution. Le texte et les insertions des messages peuvent être différents dans les mises à niveau de service et de version. Dans la mesure du possible, les ID des messages générés resteront cohérents mais ce n'est pas garanti car les implémentations sous-jacentes peuvent changer.
- L'arborescence de répertoires constituant l'installation du produit, excepté les répertoires ${wlp.install.dir}/bin et ${wlp.install.dir}/dev.
- Les exemples et les fichiers modèle dans le répertoire ${wlp.install.dir}/templates. Ces fichiers sont susceptibles d'être modifiés en cas d'application d'un correctif de maintenance à votre installation.
- Les packages Java™ privés ou émanant de fournisseurs tiers et qui ne sont pas exposés explicitement en tant qu'API. A l'exécution, ils ne sont pas visibles par le chargeur de classe de l'application.
Quels sont les éléments susceptibles d'être modifiés par l'application d'une mise à jour ou en cas de mise à niveau ?
- ${wlp.install.dir}/bin
- ${wlp.install.dir}/clients
- ${wlp.install.dir}/dev
- ${wlp.install.dir}/java
- ${wlp.install.dir}/lib
- ${wlp.install.dir}/templates
- ${wlp.install.dir}/etc (répertoire dans lequel vous avez peut-être ajouté des fichiers server.env ou jvm.options).
- ${wlp.install.dir}/usr (emplacement par défaut des configurations et applications de l'utilisateur).
- Tout répertoire que vous désignez avec la variable d'environnement WLP_USER_DIR et qui ne constitue pas l'un des répertoires par défaut.
En
théorie, aucune modification n'est apportée au contenu du répertoire
${wlp.install.dir}/etc, mais il existe une
exception. Le fichier
${wlp.install.dir}/etc/default.env est créé
lorsque vous installez Liberty sur les plateformes
IBM®
iSeries avec Installation
Manager. Ce fichier est également créé ou remplacé par la commande iAdmin
POSTINSTALL au cours de l'installation de l'archive et du gestionnaire de travaux. La commande iAdmin se trouve dans le répertoire ${wlp.install.dir}/lib/native/os400/bin. Voir Commande iAdmin.
Les API tierces changent au fil du temps sans que la compatibilité avec les versions antérieures ne soit prise en compte. Il s'agit de packages Java qui font partie de l'implémentation des fonctions développées au sein des communautés open source et distribuées avec Liberty. Les API tierces ne sont pas visibles dans les applications par défaut ; les applications Java EE comportant une configuration de chargeur de classe qui permet explicitement l'accès d'une tierce partie ne voient pas ces packages dans le chargeur de classe de l'application, et les applications OSGi doivent les importer explicitement. Prenez en compte l'impact de modifications incompatibles avant de décider d'utiliser des API de tierces parties.