Applications souples
Les applications souples sont des applications composées de plusieurs emplacements physiques, lesquels sont fournis à l'environnement d'exécution via un fichier XML. Les applications souples sont prises en charge pour les applications Java™ EE et OSGi et elles sont particulièrement utiles dans un environnement de développement.
Application normale
- Les fichiers Java archive (JAR) de bibliothèque sont stockés dans WEB-INF/lib
- Les classes figurent dans les fichiers JAR de bibliothèque ou dans WEB-INF/classes
- Le descripteur de déploiement figure dans WEB-INF/web.xml
- Le contenu à traiter se trouve à la racine du répertoire
Application souple
Une application souple est décrite comme "un répertoire virtuel qui représente l'application, dans laquelle les informations peuvent se trouver à n'importe quel emplacement". Elle permet l'utilisation des outils de développement, tels que WebSphere Application Server Developer Tools, pour exécuter des applications dans lesquelles les fichiers associés sont chargés directement depuis l'espace de travail, au lieu d'être exportés. Les fichiers associés peuvent être des classes Java, des JavaServer Pages ou des images. Si vous chargez directement les fichiers associés depuis l'espace de travail, cela se traduit par un cycle génération-exécution-débogage plus rapide. Le contenu ne se trouve pas sous un répertoire, mais il peut provenir de plusieurs autres emplacements. Ces emplacements sont spécifiés dans un fichier de configuration XML.
- En plaçant le fichier XML dans l'attribut location d'un élément de configuration d'application auquel est ajouté le suffixe .xml
- En plaçant le fichier XML directement dans le dossier dropins de l'application
Fichier de configuration de l'application souple
- Mapper un répertoire physique à un emplacement au sein de l'application
- Mapper un fichier physique à un emplacement au sein de l'application
- Mapper un fichier JAR physique ou un répertoire à un emplacement comme une archive imbriquée
- Mapper plusieurs sources physiques à un seul emplacement cible (fusion)
- Mapper la racine de l'archive à un emplacement sur disque, par exemple un dossier dans un projet Eclipse.
- Mapper un dossier Java bin/output qui n'est pas dans l'emplacement "habituel" dans le dossier WEB-INF/classes. Cet emplacement peut se trouver dans un autre dossier en raison de vos préférences d'espace de travail, de règles d'entreprise, de règles de présentation de projet de contrôle des sources, et ainsi de suite. Vous pouvez avoir plusieurs emplacements source et de sortie Java dans le même projet, et vous souhaitez les mapper à WEB-INF/classes.
- Mapper un fichier JAR "externe" dans l'application. Ce fichier JAR "externe"
peut être l'un des fichiers suivants :
- Un projet Java distinct que vous voulez traiter comme un fichier JAR dans WEB-INF/lib
- Un fichier JAR d'utilitaire ailleurs sur votre disque dur à partir duquel vous avez créé le fichier .war, et qui doit être inclus dans WEB-INF/lib lors de l'exécution
Exemples de fichiers de configuration de l'application souple
- <archive> pour les archives
- <file> pour les fichiers
- <dir> pour les répertoires
- Archives
- L'élément <archive> est toujours utilisé comme racine du fichier de configuration de l'application souple. Il est également la racine du système de fichiers virtuel qui est représenté dans XML. Vous pouvez imbriquer l'un de ces trois éléments sous l'élément <archive> de la racine. L'élément <archive> de la racine n'a pas d'attributs.
- Les éléments archive peuvent être imbriqués de façon récursive. Pour les éléments
<archive> imbriqués sous l'élément
<archive> de la racine, vous pouvez définir l'attribut
targetInArchive. L'attribut targetInArchive
définit le chemin dans lequel apparaît l'archive au sein de l'archive qui les englobe définie par
l'application souple. Vous ne pouvez pas mapper une archive au système de fichiers
en tant qu'archive dans l'application avec un élément <archive>.
Pour utiliser la configuration d'application souple afin de mapper une archive sur disque,
utilisez plutôt un élément <file>. Remarque : La valeur d'attribut targetInArchive est un chemin d'accès absolu avec une barre oblique placée au début (/).
- Voici un exemple de code de l'élément <archive> racine
avec un autre élément <archive> imbriqué au-dessous :
<archive> <archive targetInArchive="/jarName.jar"> <!-- more objects can be embedded here--> </archive> </archive>
- Fichiers
- Vous pouvez utiliser l'élément <file> pour mapper un fichier
de votre disque dur à un fichier de votre configuration d'application souple.
Vous pouvez définir les attributs suivants sur l'élément <file> :
- targetInArchive définit le chemin dans lequel apparaît l'archive au sein de l'archive qui les englobe définie par l'application souple.
- sourceOnDisk définit l'emplacement réel de votre fichier
dans votre système de fichiers. Remarque : La valeur d'attribut sourceOnDisk est un emplacement absolu. Vous pouvez utiliser des variables Liberty telles que ${example.dir}, lesquelles sont résolues correctement.
- Voici un exemple de code d'un fichier dans C:/devFolder/myApplication.zip qui est
représenté sous la forme /apps/webApplication.war par la configuration d'application souple :
<file targetInArchive="/apps/webApplication.war" sourceOnDisk="C:/devFolder/myApplication.zip" />
- Voici un exemple de code d'une archive qui les englobe et définit
une archive dans le chemin /apps/webApplication.war.
Au sein de l'archive, webApplication.war définit un fichier,
jarName.jar dans le chemin /applications/myApplications.
L'emplacement de fichier réel est c:\devFolder\myApplication.zip :
<archive targetInArchive="/apps/webApplication.war"> <file targetInArchive="/applications/myApplications/jarName.jar" sourceOnDisk="C:/devFolder/myApplication.zip" /> </archive>
- Répertoires
- Vous pouvez utiliser l'élément <dir> pour mapper un répertoire, et tout son contenu sur disque, à un emplacement de répertoire dans la configuration d'application souple. L'élément a les mêmes attributs que l'élément <file> et vous l'utilisez de la même manière.
- Le code suivant illustre un exemple de répertoire que la configuration d'application souple indique comme résidant sous
/META-INF et, sur votre système de fichiers, sous ${example.dir}/applicationData/myApplication:
<dir targetInArchive="/META-INF" sourceOnDisk="${example.dir}/applicationData/myApplication" />
- Pour ajouter le répertoire à une archive afin qu'il apparaisse comme étant dans /apps/jarName.jar/META-INF,
imbriquez l'élément <dir> comme suit :
<archive targetInArchive="/apps/jarName.jar"> <dir targetInArchive="/META-INF" sourceOnDisk="${example.dir}/applicationData/myApplication" /> </archive>
- Dans les deux exemples précédents, tous les fichiers qui figurent dans ${example.dir}/applicationData/myApplication sont mappés et visibles dans la configuration d'application souple sous le répertoire mappé par l'attribut targetInArchive.
Chemins virtuels et noms de fichier
Si vous ajoutez des éléments <file> or <dir> à une archive, le nom du fichier ou du répertoire dans l'archive souple n'est pas nécessairement identique au nom réel sur le disque.
<archive>
<file targetInArchive="/application.txt"
sourceOnDisk="${example.dir}/applicationFiles/newfile.txt"/>
</archive>
Le même concept s'applique pour le chemin de tout fichier ou répertoire ajouté. La ressource physique sur disque ne figure pas nécessairement dans une hiérarchie de répertoires qui correspond à celui déclaré.
<archive>
<file targetInArchive="/only/available/in/application.txt"
sourceOnDisk=""${example.dir}/applicationFiles/newfile.txt"/>
</archive>
<archive>
<file targetInArchive="/only/available/in/red.txt"
sourceOnDisk="${example.dir}/applicationFiles/newfile.txt" />
<archive targetInArchive="/apps/jarName.jar">
<dir targetInArchive="/META-INF"
sourceOnDisk="${example.dir}/applicationData/myApplication" />
</arhive>
</archive>
Dossiers et fichiers portant le même nom
Si vous avez deux dossiers de même nom dans le même emplacement virtuel de la configuration d'application souple, les dossiers sont fusionnés et leur contenu est disponible. Si vous avez deux fichier avec le même emplacement cible dans l'archive souple, la première occurrence du fichier est utilisée. La première occurrence repose sur une approche descendante pour la lecture des éléments du fichier de configuration d'application de l'application souple.
Si le premier fichier détecté n'est pas le bon, réorganisez le contenu XML de sorte que l'élément contenant la version du fichier souhaité soit traité en premier. La première occurrence concerne les fichiers définis dans les éléments <dir> et les fichiers qui sont définis dans les éléments <file>. La première occurrence d'un fichier portant le même nom et emplacement virtuel est celui qui est retourné par le système de fichiers virtuel.
Remarques relatives aux applications souples
Pour toutes les applications souples configurées, les fichiers ne figurent pas sur le disque au sein de la hiérarchie dans laquelle ils ont déclaré figurer. Si vos applications accèdent directement à leurs propres ressources, et si vous vous attendez à ce qu'elles soient organisées sur le disque comme elles le seraient avec un agencement war ou ear étendu, elles peuvent se comporter de manière inattendue.
Vous pouvez utiliser ServletContext.getRealPath dans vos applications pour détecter les chemins d'accès aux ressources physiques. L'élément ServletContext.getRealPath peut détecter les chemins de fichier à ouvrir pour lire ou écrire des données, et pour obtenir des répertoires. Toutefois, si vous utilisez ServletContext.getRealPath dans vos applications Web pour obtenir un chemin d'accès pour "/", vous ne pouvez pas utiliser ce chemin pour accéder à l'application sur disque.
L'élément ServletContext.getRealPath permet le renvoi d'un seul chemin physique et l'application souple a peut-être fusionné plusieurs répertoires pour former un chemin d'accès visible à l'application.
<archive>
<dir targetInArchive="/"
sourceOnDisk="c:\myapplication" />
<dir targetInArchive="/web/pages"
sourceOnDisk="c:\webpagesforapplication" />
</archive>
Une application qui accède directement à /web/pages et remonte ensuite jusqu'à la hiérarchie de répertoires, détecte que le parent du chemin d'accès physique de /web/pages est c:\ et non /web. c:\ ne comporte pas de répertoire de pages et de répertoire parent.
Ces remarques s'appliquent uniquement si vos applications essaient d'accéder directement au contenu sur disque, et si elles effectuent leur propre navigation en partant du principe qu'il existe une disposition hiérarchique correspondant sur le disque. Ces mêmes applications rencontrent également des problèmes si elles sont déployées en tant qu'archive. Elles rencontrent généralement des problèmes de portabilité.
Exemple complexe
<archive>
<dir targetInArchive="/appResources"
sourceOnDisk="${example.dir}/applicationFiles" />
<archive targetInArchive="application.jar">
<dir targetInArchive="/src"
sourceOnDisk="${example.dir}/applicationCode/src" />
</archive>
<archive targetInArchive="webApp.war">
<dir targetInArchive="/META-INF"
sourceOnDisk="${example.dir}/manifestFiles/" />
<dir targetInArchive="/WEB-INF"
sourceOnDisk="c:/myWorkspace/webAppProject/web-inf" />
<archive targetInArchive="/WEB-INF/lib/myUtility.jar">
<dir targetInArchive="/"
sourceOnDisk="c:/myWorkspace/myUtilityProject/src" />
<file targetInArchive="/someJar.jar"
sourceOnDisk="c:/myWorkspace/myUtilityProject/aJar.jar" />
</archive>
</archive>
<file targetInArchive="/myjar.jar"
sourceOnDisk="${example.dir}/apps/application.zip" />
</archive>