Flexible Anwendungen
Flexible Anwendungen sind Anwendungen, die sich aus mehreren physischen Positionen zusammensetzen, die der Laufzeit über eine XML-Datei bereitgestellt werden. Flexible Anwendungen werden für Java™ EE- und OSGi-Anwendungen unterstützt und sind in einer Entwicklungsumgebung besonders nützlich.
Normale Anwendung
- JAR-Bibliotheksdateien (Java-Archiv) sind im Verzeichnis WEB-INF/lib gespeichert.
- Klassen sind entweder in JAR-Bibliotheksdateien oder im Verzeichnis WEB-INF/classes gespeichert.
- Der Implementierungsdeskriptor befindet sich in der Datei WEB-INF/web.xml.
- Bereitzustellender Inhalt befindet sich im Stammverzeichnis des Verzeichnisses.
Flexible Anwendung
Eine flexible Anwendung wird beschrieben als "ein virtuelles Verzeichnis, das die Anwendung darstellt, wobei Informationen sich an einer beliebigen Position befinden können". Sie ermöglicht Entwicklungstools, wie z. B. WebSphere Application Server Developer Tools, Anwendungen auszuführen, bei denen die zugeordneten Dateien direkt aus dem Arbeitsbereich geladen und nicht exportiert werden. Beispiele für zugeordnete Dateien sind Java-Klassen, JavaServer Pages oder Abbildungen. Wenn Sie die zugehörigen Dateien direkt aus dem Arbeitsbereich laden, beschleunigen Sie damit den Zyklus von Build, Ausführung, und Debugging. Der Inhalt befindet sich nicht unter einem Verzeichnis, sondern kann aus anderen Positionen kommen. Diese Positionen werden in einer XML-Konfigurationsdatei angegeben.
- Sie können die XML-Datei im location-Attribut in einem Anwendungskonfigurationselement mit angehängtem Suffix .xml anordnen.
- Sie können die XML-Datei direkt in den Ordner dropins der Anwendung stellen.
Flexible Anwendungskonfigurationsdatei
- ein physisches Verzeichnis einer Position innerhalb der Anwendung zuordnen
- eine physische Datei einer Position innerhalb der Anwendung zuordnen
- eine physische JAR-Datei oder ein physisches Verzeichnis einer Position als verschachteltes Archiv zuordnen
- mehrere physische Quellen einer einzigen Zielposition zuordnen (Zusammenführung)
- Sie können das Stammverzeichnis des Archivs einer Position auf Platte, z. B. einem Ordner in einem Eclipse-Projekt, zuordnen.
- Sie können einen Java-Ordner bin/output, der sich nicht an der "üblichen" Position befindet, dem Ordner WEB-INF/classes zuordnen. Diese Position könnte sich aufgrund Ihrer Arbeitsbereichsvorgaben, Unternehmensrichtlinien, Layoutrichtlinien für Quellcodeverwaltungsprojekte usw. in einem anderen Ordner befinden. Möglicherweise haben Sie mehrere Java-Quellcode- und -Ausgabepositionen im selben Projekt und möchten sie beide dem Verzeichnis WEB-INF/classes zuordnen.
- Sie können eine "externe" JAR-Datei der Anwendung zuordnen. Diese "externe" JAR-Datei kann Folgendes sein:
- ein eigenständiges Java-Projekt, das Sie wie eine JAR-Datei im VerzeichnisWEB-INF/lib handhaben möchten
- eine Dienstprogramm-JAR-Datei an einer anderen Stelle auf Ihrem Festplattenlaufwerk, mit der Sie die .war-Datei erstellt haben und die Sie zur Laufzeit in das Verzeichnis WEB-INF/lib einschließen müssen
Beispiele für flexible Anwendungskonfigurationsdateien
- <archive> für Archive
- <file> für Dateien
- <dir> für Verzeichnisse
- Archive
- Das Element <archive> wird immer als Stammverzeichnis der flexiblen Anwendungskonfigurationsdatei verwendet. Es ist auch das Stammverzeichnis des virtuellen Dateisystems, das in der XML-Datei dargestellt wird. Sie können jedes der drei Elemente unter dem <archive>-Stammelement verschachteln. Das <archive>-Stammelement hat keine Attribute.
- Archivelemente können rekursiv verschachtelt werden. Für <archive>-Elemente, die unter dem
<archive>-Stammelement verschachtelt sind, können Sie das Attribut
targetInArchive festlegen. Das Attribut targetInArchive definiert den Pfad, unter dem das Archiv
innerhalb des flexibel definierten übergeordneten Archivs erscheint. Sie können mit einem <archive>-Element ein auf dem Dateisystem befindliches Archiv nicht als Archiv in der Anwendung zuordnen. Wenn Sie mit einer flexiblen Anwendungskonfiguration ein Archiv auf Platte zuordnen möchten,sollten Sie stattdessen ein <file>-Element verwenden. Anmerkung: Der Wert des Attributs targetInArchive ist ein absoluter Pfad mit einem führenden normalen Schrägstrich (/).
- Der folgende Code ist ein Beispiel für das <archive>-Stammelement mit einem weiteren, verschachtelten
<archive>-Element:
<archive> <archive targetInArchive="/jarName.jar"> <!-- Hier können weitere Objekte integriert werden --> </archive> </archive>
- Dateien
- Sie können das <file>-Element verwenden, um eine Datei auf Ihrer Festplatte einer Datei in Ihrer flexiblen Anwendungskonfiguration zuzuordnen. Sie können die folgenden Attribute im <file>-Element festlegen:
- targetInArchive definiert den Pfad, unter dem das Archiv innerhalb des flexibel definierten übergeordneten Archivs erscheint.
- sourceOnDisk definiert die tatsächliche Position Ihrer Datei in Ihrem Dateisystem. Anmerkung: Der Wert des Attributs sourceOnDisk ist ein absoluter Pfad. Sie können Liberty-Variablen wie ${example.dir} verwenden, die ordnungsgemäß aufgelöst werden.
- Der folgende Code ist ein Beispiel für eine Datei in C:/devFolder/myApplication.zip, die von der flexiblen Anwendungskonfiguration als Datei /apps/webApplication.war dargestellt wird:
<file targetInArchive="/apps/webApplication.war" sourceOnDisk="C:/devFolder/myApplication.zip" />
- Der folgende Code ist ein Beispiel für ein übergeordnetes Archiv, das ein Archiv unter dem Pfad /apps/webApplication.war definiert. Innerhalb des Archivs definiert webApplication.war die Datei jarName.jar unter dem Pfad /applications/myApplications. Die tatsächliche Dateiposition ist c:\devFolder\myApplication.zip:
<archive targetInArchive="/apps/webApplication.war"> <file targetInArchive="/applications/myApplications/jarName.jar" sourceOnDisk="C:/devFolder/myApplication.zip" /> </archive>
- Verzeichnisse
- Sie können das Element <dir> verwenden, um ein Verzeichnis und seinen gesamten auf Platte befindlichen Inhalt einer Verzeichnisposition in der flexiblen Anwendungskonfiguration zuzuordnen. Das Element hat die gleichen Attribute wie das <file>-Element und wird ähnlich verwendet.
- Der folgende Code ist ein Beispiel für ein Verzeichnis, das sich laut flexibler Anwendungskonfiguration
im Verzeichnis /META-INF und auf Ihrem Dateisystem im Verzeichnis
${example.dir}/applicationData/myApplication befindet:
<dir targetInArchive="/META-INF" sourceOnDisk="${example.dir}/applicationData/myApplication" />
- Wenn Sie das Verzeichnis einem Archiv hinzufügen möchten, sodass es im Pfad /apps/jarName.jar/META-INF erscheint, müssen Sie das <dir>-Element wie folgt integrieren:
<archive targetInArchive="/apps/jarName.jar"> <dir targetInArchive="/META-INF" sourceOnDisk="${example.dir}/applicationData/myApplication" /> </archive>
- In beiden zuvor genannten Beispielen werden alle in ${example.dir}/applicationData/myApplication befindlichen Dateien in der flexiblen Anwendungskonfiguration unter dem vom Attribut targetInArchive zugewiesenen Verzeichnis zugeordnet und angezeigt.
Virtuelle Pfade und Dateinamen
Wenn Sie <file>- oder <dir>-Elemente einem Archiv hinzufügen, muss der Name der Datei oder des Verzeichnisses im flexiblen Archiv nicht mit dem tatsächlichen Namen auf Platte identisch sein.
<archive>
<file targetInArchive="/application.txt"
sourceOnDisk="${example.dir}/applicationFiles/newfile.txt"/>
</archive>
Dasselbe Konzept ist auch für den Pfad einer hinzugefügten Datei oder eines hinzugefügten Verzeichnis gültig. Die physische Ressource auf Platte muss sich nicht in einer Verzeichnishierarchie befinden, die der zu deklarierenden Hierarchie entspricht.
<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>
Ordner und Dateien mit demselben Namen
Wenn Sie zwei Ordner mit demselben Namen an derselben virtuellen Position in der Konfiguration der flexiblen Anwendung haben, werden die Ordner zusammengeführt, und die Inhalte beider Ordner sind verfügbar. Wenn Sie zwei Dateien mit derselben Zielposition im flexiblen Archiv haben, wird das erste Vorkommen der Datei verwendet. Das erste Vorkommen basiert auf einem Top-down-Ansatz zum Lesen der Elemente der flexiblen Anwendungskonfigurationsdatei.
Wenn die erste gefundene Datei die falsche ist, ordnen Sie die XML-Datei neu, damit das Element, das die Version der gewünschten Datei enthält, zuerst verarbeitet wird. Zuerst kommen Dateien vor, die in <dir>- und <file>-Elementen definiert sind. Die erste Datei mit demselben Namen und derselben virtuellen Position, die vorkommt, wird vom virtuellen Dateisystem zurückgegeben.
Hinweise zu flexiblen Anwendungen
Für alle flexibel konfigurierten Anwendungen gilt, dass die Dateien sich nicht auf Platte in der Hierarchie befinden, für die sie deklariert sind. Wenn Ihre Anwendungen direkt auf ihre eigenen Ressourcen zugreifen und davon ausgehen, dass die Ressourcen auf Platte angeordnet werden, wie das bei einem erweiterten war- oder ear-Layout der Fall wäre, zeigen sie möglicherweise ein nicht erwartetes Verhalten.
Sie können in Ihren Anwendungen ServletContext.getRealPath verwenden, um physische Ressourcenpfade zu erkennen. ServletContext.getRealPath kann Dateipfade erkennen, die geöffnet werden müssen, um Daten zu lesen oder zu schreiben und Verzeichnisse abzurufen. Wenn Sie ServletContext.getRealPath jedoch in Webanwendungen verwenden, um einen Pfad für "/" abzurufen, können Sie diesen Pfad nicht verwenden, um in der Anwendung auf Platte zu navigieren.
ServletContext.getRealPath lässt nur die Rückgabe eines einzelnen physischen Pfads zu, doch die flexible Anwendung hat möglicherweise mehrere Verzeichnisse zusammengeführt, um einen für die Anwendung sichtbaren Pfad zu bilden.
<archive>
<dir targetInArchive="/"
sourceOnDisk="c:\myapplication" />
<dir targetInArchive="/web/pages"
sourceOnDisk="c:\webpagesforapplication" />
</archive>
Eine Anwendung, die direkt auf /web/pages zugreift und sich dann in der Verzeichnishierarchie aufwärts bewegt, stellt fest, dass die übergeordnete Ebene des physischen Pfads von /web/pages nicht /web ist, sondern c:\. c:\ hat kein Seitenverzeichnis und kein übergeordnetes Verzeichnis.
Diese Hinweise gelten nur, wenn Ihre Anwendungen versuchen, direkt auf den Inhalt auf Platte zuzugreifen und ihre eigene Pfadnavigation durchführen, vorausgesetzt, es besteht ein entsprechendes hierarchisches Layout auf Platte. Bei denselben Anwendungen treten auch Probleme auf, wenn sie als Archiv implementiert werden. Diese Anwendungen können im Allgemeinen nicht problemlos portiert werden.
Komplexes Beispiel
<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>