Befehl "JSPBatchCompiler"
Der Stapelcompiler validiert die Syntax der JavaServer Pages (JSP), setzt die JSP-Seiten in Java™-Quellendateien um und kompiliert diese in Java-Servlet-Klassendateien. Der Stapelcompiler validiert auch Tag-Dateien und generiert deren Java-Implementierungsklassen. Verwenden Sie diese Funktion, um Ihre JSP-Dateien im Stapelbetrieb zu kompilieren und somit schnellere Antworten auf die ersten Clientanforderungen für die JSP-Dateien auf Ihrem Webproduktionsserver zu ermöglichen.
Sie können den Stapelcompiler für komprimierte oder entpackte EAR-Dateien und WAR-Dateien sowie für Unternehmensanwendungen und Webmodule ausführen, die in WebSphere Application Server implementiert wurden. Wenn das Ziel eine implementierte Unternehmensanwendung ist, ist es nicht erforderlich, dass der Server zur Ausführung des Stapelcompilers aktiv ist. Wenn der Stapelcompiler ausgeführt wird, während der Zielserver aktiv ist, kann der Server eine aktualisierte Klassendatei nicht erkennen und lädt diese Klassendatei folglich nicht, es sei denn, die Unternehmensanwendung wird erneut gestartet. Ist das Ziel eine komprimierte EAR- oder WAR-Datei, muss der Stapelcompiler die Datei zunächst entpacken.
Webmodule verarbeiten
Der Stapelcompiler bearbeitet nur jeweils ein Webmodul. Ist das Ziel eine EAR-Datei oder eine installierte Unternehmensanwendung mit mehreren Webmodulen, verarbeitet der Stapelcompiler jedes Webmodul einzeln. Dies ist erforderlich, weil JSPs auf Webmodulbasis mit der Implementierungsdeskriptordatei web.xml des Webmoduls konfiguriert werden. In einem Webmodul bearbeitet der Stapelcompiler jeweils ein Verzeichnis. Er wertet jede JSP gesondert aus und setzt sie um. Anschließend wird ein Java-Compiler für alle generierten Java-Quellendateien in diesem Verzeichnis aufgerufen. Tritt während der Java-Kompilierung bei einer JSP ein Fehler auf, kann der Java-Compiler unter Umständen keine Klassendateien für einige oder alle JSPs erstellen, auch wenn diese erfolgreich kompiliert werden konnten.
Erweiterungen von JSP-Dateien
- Standarderweiterungen von JSP-Dateien
- .jsp
- .jspx
- .jsw
- .jsv
- Die Eigenschaft "url-pattern" der jsp-property-group-Elemente in der Implementierungsdeskriptordatei in Servlet-2.4-Webmodulen
- Konfigurationsparameter jsp.file.extensions der JSP-Engine (für Webmodule gemäß einer Vorversion von Servlet 2.4)
- Der Konfigurationsparameter jsp.file.extensions des Stapelcompilers
Die Standarderweiterungen werden immer vom Stapelcompiler verwendet. Wenn das Webmodul einen Implementierungsdeskriptor der Servlet Version 2.4 enthält, verarbeitet der Stapelcompiler auch alle url-patterns im jsp-config-Element. Wenn das Ziel des Stapelcompilers den Konfigurationsparameter jsp.file.extensions der JSP-Engine enthält, werden diese Erweiterungen ebenfalls verarbeitet. Ist der Konfigurationsparameter jsp.file.extensions des Stapelcompilers vorhanden, werden die angegebenen Erweiterungen ebenfalls verarbeitet und überschreiben den Konfigurationsparameter jsp.file.extensions der JSP-Engine.
Es empfiehlt sich, 'fragments' mit einer Erweiterung zu versehen, die vom Stapelcompiler nicht verarbeitet wird. Statisch aufgenommene Fragmente, die nicht abgesondert wurden, generieren bei der Verarbeitung Umsetzungs- oder Kompilierungsfehler. Die Spezifikation JSP 2.0 schlägt die Verwendung der Erweiterung .jspf für solche Dateien vor.
Befehl des Stapelcompilers
Im Verzeichnis
{WAS_ROOT}/bin befinden sich sowohl die
Windows-StapeldateiJspBatchCompiler.bat als auch das
UNIX-Shell-Script
JspBatchCompiler.sh zur Ausführung des Stapelcompilers über die Befehlszeile.
Für die Ausführung
des Stapelcompilers mit Ant ist auch eine Ant-Task vorhanden. Weitere Informationen finden Sie im Artikel "Ant-Task für Stapelcompiler".
Da Script
JspBatchCompiler für die Ausführung des Stapelcompilers über die Qshell-Befehlszeile
finden Sie im Verzeichnis Stammverzeichnis_des_Anwendungsservers/bin.
Für die Ausführung
des Stapelcompilers mit Ant ist auch eine Ant-Task vorhanden. Weitere Informationen finden Sie im Artikel "Ant-Task für Stapelcompiler".
JspBatchCompiler -ear.path | -war.path | -enterpriseapp.name <Name>
[-response.file <Dateiname>]
[-webmodule.name <Name>]
[-filename <JSP-Name | Verzeichnisname>
[-recurse <true | false>]
[-config.root <Pfad>]
[-cell.name <Name>]
[-cluster.name <Name>] [-node.name <Name>]
[-server.name <Name>]
[-profileName <Name>]
[-extractToDir <Pfad>]
[-compileToDir <Pfad>]
[-compileToWebInf <true | false>]
[-compileToWebInf <true | false>]
[-compileAfterFailure <true | false>]
[-translate <true | false>]
[-compile <true | false>]
[-removeTempDir <true | false>]
[-forceCompilation <true | false>]
[-useFullPackageNames <true | false>]
[-trackDependencies <true | false>]
[-createDebugClassfiles <true | false>]
[-keepgenerated <true | false>]
[-keepGeneratedclassfiles <true | false>]
[-usePageTagPool <true | false>]
[-useThreadTagPool <true | false>]
[-classloader.parentFirst <true | false>]
[-classloader.singleWarClassloader <true | false>]
[-additional.classpath <Klassenpfad zu weiteren JAR-Dateien und Klassen>]
[-verbose <true | false>]
[-deprecation <true | false>]
[-javaEncoding <Codierung>
[-jdkSourceLevel <13 | 14 | 15 | 16 | 17 | 18 >]
[-compilerOptions <durch Leerzeichen getrennte Liste mit Optionen für den Java-Compiler>]
[-useJikes <true | false>]
[-jsp.file.extensions <zu verarbeitende Dateierweiterungen>]
[-log.level <SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST | OFF>]
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
*** Weitere Informationen finden Sie in der Datei batchcompiler.properties.default in WAS_ROOT/bin. ***
*** Weitere Informationen zur allgemein zugänglichen WebSphere-Ant-Task JspC finden Sie in der Datei JspCBuild.xml im Verzeichnis WAS_ROOT/bin.***
![[IBM i]](../images/iseries.gif)
*** Weitere Informationen finden Sie in der Datei batchcompiler.properties.default in Stammverzeichnis_des_Anwendungsservers/bin. ***
*** Weitere Informationen zur allgemein zugänglichen WebSphere-Ant-Task JspC finden Sie in der Datei JspCBuild.xml im Verzeichnis Stammverzeichnis_des_Anwendungsservers/bin.
***
- Konfigurationsparameter der JSP-Engine für ein Webmodul
Weitere Informationen finden Sie im Artikel zu den Konfigurationsparametern für die JSP-Engine.
- Konfigurationsparameter der Antwortdatei des Stapelcompilers
Diese Parameter sind in einer Antwortdatei des Stapelcompilers enthalten. Lesen Sie hierzu die Informationen zu -response.file.
- Konfigurationsparameter für die Befehlszeile des Stapelcompilers
Diese Parameter werden in der Befehlszeile eingegeben, wenn Sie den Stapelcompiler ausführen.
- Wenn der Parameter in der Befehlszeile gefunden wird, wird sein Wert verwendet.
- Wenn der Parameter nicht in der Befehlszeile gefunden wird, sucht der Stapelcompiler in der Antwortdatei, die in der Befehlszeile angegeben ist, nach dem Parameter.
- Falls keine Antwortdatei angegeben ist oder der Parameter in der angegeben Datei nicht gefunden wird, sucht der Stapelcompiler in den Konfigurationsparametern der JSP-Engine des Webmoduls nach dem Parameter.
Kann ein Konfigurationsparameter in keiner der drei Gruppen gefunden werden, wird der Standardwert verwendet. Die Standardwerte für die Konfigurationsparameter sind zusammen mit der Beschreibung der Parameter angegeben.
Bei den Parametern wird mit Ausnahme des Parameters "-profileName" nicht zwischen Groß- und Kleinschreibung unterschieden. Wenn die für diese Parameter angegebenen Werte zwei oder mehr durch Leerzeichen getrennte Wörter umfassen, müssen Sie die Werte in Anführungszeichen setzen.
Der Stapelcompiler kann keine Parameter erstellen, die den Parametern der JSP-Engine äquivalent wären, oder Werte solcher Parameter festlegen. Wird eine JSP in einem implementierten Webmodul modifiziert oder zur Laufzeit erneut von der JSP-Engine kompiliert, richtet sich das Verhalten der Engine somit nach den Konfigurationsparametern der JSP-Engine. Wenn Sie mit dem Stapelcompiler beispielsweise ein Webmodul kompilieren und die Option "-useFullPackageNames true" verwenden, werden die JSP-Dateien für die Unterstützung dieser Option kompiliert. Der Parameter "useFullPackageNames" der JSP-Engine muss allerdings auch auf true gesetzt werden, damit die JSP-Laufzeit die kompilierten JSPs laden kann. Werden JSPs in einem implementierten Webmodul modifiziert, sollten die Parameter der Engine auf die während der Stapelkompilierung verwendeten Werte gesetzt werden.
Wenn Sie den JSP-Stapelcompiler verwenden möchten, geben Sie an einer Eingabeaufforderung des Betriebssystems den folgenden Befehl in einer Zeile ein:
- ear.path | war.path | enterpriseapp.name Er repräsentiert den vollständigen Pfad zu einer komprimierten oder entpackten EAR- oder WAR-Datei oder den Namen der zu kompilierenden implementierten Unternehmensanwendung. Beispiele:
JspBatchCompiler -ear.path c:\myproject\sampleApp.ear
JspBatchCompiler -ear.path /myhfs/myprojects/sampleApp.ear
JspBatchCompiler -war.path c:\myWars\examples.war
JspBatchCompiler -enterpriseapp.name myEnterpriseApp -webmodule.name my.war -filename aDir/main.jsp
JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear
JspBatchCompiler -war.path /home/wasuser/wars/examples.war
JspBatchCompiler -enterpriseapp.name myEnterpriseApp -webmodule.name my.war -filename mydirectory/main.jsp
- response.file
Gibt den Pfad zu einer Datei an, die die vom Stapelcompiler verwendeten Konfigurationsparameter enthält. Der Parameter response.file wird nur verwendet, wenn er in der Befehlszeile angegeben wurde; er wird ignoriert, wenn er in einer Antwortdatei vorhanden ist.
In einer Standardinstallation ist die Schablonenantwortdatei batchcompiler.properties.default im Verzeichnis {WAS_ROOT}/bin gespeichert. Kopieren Sie diese Schablone, um Ihre eigenen Antwortdateien mit Standardwerten für die Parameter, an denen Sie interessiert sind, zu erstellen. Alle erforderlichen und optionalen Parametern (außer response.file) können in einer Antwortdatei konfiguriert werden. Beispiel: JspBatchCompiler -response.file c:\myproject\batchc.props
Eine Schablonenantwortdatei, batchcompiler.properties.default, befindet sich im Verzeichnis Stammverzeichnis_des_Anwendungsservers/properties. Kopieren Sie diese Schablone, um Ihre eigenen Antwortdateien mit Standardwerten für die Parameter, an denen Sie interessiert sind, zu erstellen. Sie können alle erforderlichen und optionalen Parameter mit Ausnahme der Datei response.file in einer Antwortdatei konfigurieren. Beispiel: JspBatchCompiler -response.file /home/wasuser/myproject/batchc.props.
Standardeinstellung: null
- webmodule.name
Bezeichnet den Namen des Webmoduls, das Sie im Stapelbetrieb kompilieren möchten. Wenn dieses Argument nicht gesetzt ist, werden alle Webmodule in der Unternehmensanwendung kompiliert. Dieser Parameter wird nur verwendet, wenn ear.path oder enterpriseapp.name angegeben ist. Dieser Parameter ist sinnvoll, wenn JSPs eines spezifischen Webmoduls innerhalb einer implementierten Unternehmensanwendung erneut generiert werden müssen, weil alle von gemeinsam genutzten Bibliotheken abhängigen Dateien erfasst werden.
Beispiel: JspBatchCompiler -enterpriseApp.name Beispielanwendung -webmodule.name meinWebmodul.war
Standardeinstellung: Wenn dieser Parameter nicht angegeben ist, werden alle Webmodule einer EAR-Datei oder Unternehmensanwendung kompiliert.
- filename
Bezeichnet den Namen einer einzelnen JSP-Datei, die Sie kompilieren möchten. Wenn dieses Argument nicht definiert ist, werden alle Dateien im Webmodul kompiliert. Wenn für filename hingegen der Name eines Verzeichnisses angegeben ist, werden nur die JSP-Dateien in diesem Verzeichnis und dessen Unterverzeichnissen kompiliert. Der Name ist der relative Name im Kontextstammverzeichnis des Webmoduls.
Beispiel 1: Wenn Sie die Datei meinTest.jsp im Verzeichnis /Unterverzeichnis/meineJSPs kompilieren möchten, müssen Sie -filename /Unterverzeichnis/meineJSPs/meinTest.jsp angeben.
Beispiel 2: Wenn Sie alle JSP-Dateien in /Unterverzeichnis/meineJSPs und den diesem Verzeichnis untergeordneten Verzeichnissen kompilieren möchten, müssen Sie -filename Unterverzeichnis/meineJSPs eingeben.
Standardeinstellung: Es werden alle JSP-Dateien im Webmodul kompiliert. Die Eingabe von -filename / entspricht der Standardeinstellung.
- recurse
Legt fest, ob Unterverzeichnisse des Zielverzeichnisses verarbeitet werden. Dieser Parameter wird nur verwendet, wenn der Parameter filename angegeben ist. Setzen Sie den Wert auf false, um nur das im Parameter filename angegebene Verzeichnis und nicht dessen Unterverzeichnisse zu verarbeiten.
Beispiel: JspBatchCompiler -enterpriseApp.name Beispielanwendung -filename /Unterverzeichnis1 -recurse false
Standardeinstellung: true. Es werden alle Unterverzeichnisse des Zielverzeichnisses mit verarbeitet.
- config.root
Gibt die Position des WebSphere Application Server-Konfigurationsverzeichnisses an. Dieser Parameter wird nur verwendet, wenn enterpriseapp.name angegeben ist.
Standardeinstellung: {WAS_ROOT}/profiles/profilename/config
Standardeinstellung: Profilstammverzeichnis/config
- cell.name
Bezeichnet den Namen der Zelle, in der die Anwendung implementiert wird. Dieser Parameter wird nur verwendet, wenn enterpriseapp.name angegeben ist.
Standardeinstellung: Die Standardeinstellung wird aus dem verwendeten Profilscript abgerufen. Der symbolische Name dieser Variablen ist WAS_CELL.
- cluster.name
Bezeichnet den Namen des Clusters, in dem die Anwendung implementiert wird. Dieser Parameter ermöglicht dem Stapelcompiler den Zugriff auf gemeinsam genutzte Bibliotheken im Clusterbereich und wird nur dann verwendet, wenn enterpriseapp.name angegeben ist.
Standardeinstellung: Die Standardeinstellung wird aus dem verwendeten Profilscript abgerufen. Der symbolische Name dieser Variablen ist WAS_CLUSTER.
- node.name
Bezeichnet den Namen des Knotens, auf dem die Anwendung implementiert wird. Dieser Parameter wird nur verwendet, wenn enterpriseapp.name angegeben ist.
Standardeinstellung: Die Standardeinstellung wird aus dem verwendeten Profilscript abgerufen. Der symbolische Name dieser Variablen ist WAS_NODE.
- server.name
Bezeichnet den Namen des Servers, auf dem die Anwendung implementiert wird. Dieser Parameter wird nur verwendet, wenn enterpriseapp.name angegeben ist.
Standardeinstellung: server1
- profileName
Gibt den Namen des zu verwendenden Profils an. Dieser Parameter wird nur verwendet, wenn der Pfad von enterpriseapp.name oder -ear angegeben ist.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -profileName AppServer-3
Standardeinstellung: Es wird das Standardprofil verwendet. Es wird aus der Scriptdatei setupCmdLine im Verzeichnis install_root/bin abgerufen. Der symbolische Name ist DEFAULT_PROFILE_SCRIPT.
Standardeinstellung: Es wird das Standardprofil verwendet. Es wird aus der Scriptdatei setupCmdLine im Verzeichnis Stammverzeichnis_des_Anwendungsservers/bin abgerufen. Der symbolische Name ist DEFAULT_PROFILE_SCRIPT.
- extractToDir
Gibt das Verzeichnis an, in dem die vorab implementierten EAR- und WAR-Dateien extrahiert werden, bevor sie vom Stapelcompiler verarbeitet werden. Dieser Parameter wird ignoriert, wenn enterpriseapp.name angegeben ist. Der Parameter "extractToDir" wird wie in der Tabelle angegeben verwendet.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -extractToDir c:\mBeispielyTempDir.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -extractToDir /home/wasuser/mytempdir.
Anwendungsfall: Ein komprimiertes Archiv muss vor der Kompilierung im Stapelbetrieb extrahiert werden. Sie können auch ein bereits entpacktes Archiv in ein neues Verzeichnis extrahieren. Das ursprüngliche Archiv bleibt in beiden Fällen unberührt, was bei laufendem Deployment hilfreich sein kann.
Tabelle 1. extractToDir. Standardwerte Entpacktes Archiv Komprimiertes Archiv extractToDir angegeben Der Stapelcompiler extrahiert das Archiv vor der Verarbeitung in das Verzeichnis extractToDir. Falls im extractToDir bereits eine Datei oder ein Verzeichnis mit dem Namen des Archivs vorhanden ist, entfernt der Stapelcompiler das Archiv vor dem Extrahieren. Wird der Stapelcompiler ohne Fehler beendet, komprimiert er das Archiv im extractToDir, auch wenn die Original-EAR-Datei oder -WAR-Datei entpackt war. Werden bei der Kompilierung Fehler festgestellt, bleibt die EAR- oder WAR-Datei entpackt, auch wenn die Original-EAR-Datei oder -WAR-Datei komprimiert war. extractToDir nicht angegeben Der Stapelcompiler verarbeitet die EAR- oder WAR-Datei, ohne sie in ein anderes Verzeichnis zu extrahieren. Nach Beendigung des Stapelcompilers bleibt das Archiv entpackt. Der Stapelcompiler extrahiert das Archiv in das von der JVM-Eigenschaft "java.io.tmpdir" zurückgegebene Verzeichnis. Im Übrigen entspricht das Verhalten des Compilers dem Verhalten bei Angabe von "extractToDir". Die Standardeinstellung ist server1.
- compileToDir
Gibt das Verzeichnis an, in dem die JSPs in Java-Quellendateien umgesetzt und in Klassendateien kompiliert werden. Dieses Verzeichnis kann sich an beliebiger Stelle im Dateisystem befinden, aber das Standardverhalten des Stapelcompilers ist in der Regel angemessen. Das Verhalten des Stapelcompilers beim Kompilieren der Klassendateien ist in der Tabelle beschrieben.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -compileToDir c:\myTargetDir
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -compileToDir /home/wasuser/myTargetDir
Anwendungsfall: Bei Verwendung dieses Parameters werden die Java- und Klassendateien in einem anderen Verzeichnis als dem Zielverzeichnis generiert. Dies kann hilfreich sein, wenn Sie die neu generierten Dateien mit der unveränderten früheren Version im Zielverzeichnis vergleichen möchten.
Tabelle 2. compileToDir . Standardwerte ear.path oder war.path angegeben enterpriseApp.name angegeben compileToDir nicht angegeben; compileToWebInf nicht angegeben oder auf true gesetzt Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. compileToDir nicht angegeben; compileToWebInf auf false gesetzt Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. Die Klassendateien werden kompiliert und in das temporäre Produktverzeichnis (in der Regel {WAS_ROOT}/temp) gestellt. compileToDir angegeben; compileToWebInf nicht angegeben oder auf true/false gesetzt Die Klassendateien werden kompiliert und in das von compileToDir angegebene Verzeichnis gestellt. Die Klassendateien werden kompiliert und in das von compileToDir angegebene Verzeichnis gestellt. Tabelle 3. compileToDir . Standardwerte ear.path oder war.path angegeben enterpriseApp.name angegeben compileToDir nicht angegeben; compileToWebInf nicht angegeben oder auf true gesetzt Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. compileToDir nicht angegeben; compileToWebInf auf false gesetzt Die Klassendateien werden kompiliert und in das Webmodulverzeichnis WEB-INF/classes gestellt. Die Klassendateien werden kompiliert und in das temporäre Produktverzeichnis (in der Regel Profilstammverzeichnis/temp) gestellt. compileToDir angegeben; compileToWebInf nicht angegeben oder auf true/false gesetzt Die Klassendateien werden kompiliert und in das von compileToDir angegebene Verzeichnis gestellt. Die Klassendateien werden kompiliert und in das von compileToDir angegebene Verzeichnis gestellt. - compileToWebInf
Gibt an, ob das Webmodulverzeichnis WEB-INF/classes das Zielverzeichnis für die kompilierten JSP-Klassendateien sein soll. Dieser Parameter wird nur verwendet, wenn enterpriseApp.name angegeben ist. Er wird von compileToDir außer Kraft gesetzt, sofern compileToDir angegeben ist.
Standardmäßig stellt der Stapelcompiler die kompilierten Dateien in das Webmodulvervzeichnis WEB-INF/classes. Das Verhalten des Stapelcompilers beim Kompilieren der Klassendateien ist in der Tabelle beschrieben.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -compileToWebInf false.
Anwendungsfall: Setzen Sie diesen Parameter auf false, wenn enterpriseApp.name angegeben ist und die kompilierten Klassendateien in das temporäre Verzeichnis von WebSphere Application Server und nicht in das Webmodulverzeichnis WEB-INF/classes gestellt werden sollen. Empfehlung: Wenn dieser Parameter auf false gesetzt ist, sollten Sie forceCompilation auf true setzen, sofern das Verzeichnis WEB-INF/classes JSP-Klassendateien enthält.
Standardeinstellung: true; siehe Tabelle.
- compileAfterFailure
Gibt an, ob der JDK-JSP-Stapelcompiler mit der Kompilierung der anderen JSP-Dateien im aktuellen Verzeichnis fortfährt, wenn eine oder mehrere JSP-Dateien in diesem Verzeichnis nicht kompiliert werden können. Wenn eine der Dateien nicht kompiliert werden kann, überspring der JSP-Stapelcompiler gewöhnlich alle verbleibenden JSP-Dateien in diesem Verzeichnis und beginnt mit der Kompilierung der Dateien im nächsten Verzeichnis.
Wenn Sie diesen Parameter auf "true" setzen, müssen Sie auch den Parameter "useJDKCompiler" definieren und auf "true" setzen.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -useJDKCompiler true –compileAfterFailure false.
Anwendungsfall: Setzen Sie diesen Parameter auf "true", wenn der JSP-Stapelcompiler die anderen JSP-Dateien im aktuellen Verzeichnis auch dann kompilieren soll, wenn eine oder mehrere JSP-Dateien in diesem Verzeichnis nicht kompiliert werden können.
Standardeinstellung: false
- forceCompilation
Gibt an, ob der Stapelcompiler in jedem Fall alle JSP-Ressourcen erneut kompilieren soll, auch wenn die JSP veraltet ist.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -forceCompilation true.
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -forceCompilation true.
Anwendungsfall: Dieser Parameter ist insbesondere bei Erstellung eines Archivs für die Implementierung hilfreich, um sicherzustellen, dass alle JSP-Klassen auf dem neuesten Stand sind.
Standardeinstellung: false
- useFullPackageNames
Gibt an, ob der Stapelcompiler vollständige Paketnamen für JSP-Klassen generiert. Standardmäßig werden alle JSP-Klassen im selben Paket generiert. Der Klassenlader der JSP-Engine kann JSP-Klassen laden, wenn sie sich alle im selben Paket befinden. Die Standardeinstellung bietet den Vorteil, dass sie kompakte Dateisystempfade generiert. Vollständige Paketnamen haben den Vorteil, dass die Konfiguration von vorkompilierten JSP-Klassendateien als Servlets in der Datei web.xml ohne Verwendung des Attributs jsp-file aktiviert werden. Dies führt dazu, dass ein einzelner Klassenlader entsteht (der Klassenlader der Webanwendung), der zum Laden aller JSP-Klassen dieses Typs verwendet wird. Wenn die Konfigurationsattribute useFullPackageNames und disableJspRuntimeCompilation auf true gesetzt sind, wird ebenfalls nur ein Klassenlader für das Laden aller JSP-Klassen verwendet. Dies gilt auch, wenn die JSPs nicht als Servlets in der Datei web.xml konfiguriert sind.
Wenn useFullPackageNames auf "true" gesetzt ist, generiert der Batch-Compiler die Datei generated_web.xml im Verzeichnis WEB-INF des Webmoduls. Diese Datei enthält Servletkonfigurationsdaten für jede fehlerfrei umgesetzte und kompilierte JSP. Optional können die Daten in die Datei web.xml des Webmoduls kopiert werden, damit die JSPs vom Web-Container als Servlets geladen werden. Ist eine JSP auf diese Weise als Servlet konfiguriert, ist ein erneutes Laden der JSP im Falle einer Modifizierung der JSP nicht möglich. Dies liegt daran, dass die JSP wie ein reguläres Servlet behandelt wird und Anforderungen an dieses Servlet nicht an die JSP-Engine weitergeleitet werden.
Beispiel: JspBatchCompiler –enterpriseApp.name sampleApp –useFullPackageNames true
Anwendungsfall: JSP-Klassen können von nur einem Klassenlader geladen werden.
Standardeinstellung: false
- removeTempDir
Gibt an, ob das temporäre Verzeichnis des Webmoduls entfernt wird. Der Stapelcompiler stellt die generierten JSP-Klassendateien standardmäßig in das Webmodulverzeichnis WEB-INF/classes. Zur Laufzeit werden generierte JSP-Klassendateien in das Verzeichnis temp gestellt, wenn eine JSP modifiziert wurde und das erneute Laden von JSPs aktiviert ist. Sie sparen Plattenressourcen, wenn Sie alle JSPs in einem Webmodul im Stapelbetrieb kompilieren und das Verzeichnis temp entfernen. Sie können den Parameter removeTempDir nur verwenden, wenn -enterpriseApp.name angegeben ist.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -removeTempDir true.
Anwendungsfall: Geben Sie Plattenspeicherplatz frei, indem Sie das Verzeichnis temp einer Webanwendung löschen.
Standardeinstellung: false
- translate
Gibt an, ob JSPs umgesetzt und kompiliert werden. Setzen Sie translate auf false, wenn JSPs nicht umgesetzt und kompiliert werden sollen. Sie müssen diese Option zusammen mit -removeTempDir verwenden, um den Stapelcompiler anzuweisen, dass nur das Verzeichnis temp entfernt werden soll und keine weiteren Verarbeitungsschritte erforderlich sind.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -translate false -removeTempDir true.
Anwendungsfall: Geben Sie Plattenspeicherplatz frei, indem Sie das Verzeichnis temp einer Webanwendung löschen, ohne die JSP-Verarbeitung aufzurufen.
Standardeinstellung: true
- compile
Gibt an, ob JSPs die Java-Kompilierung durchlaufen sollen. Setzen Sie compile auf false, wenn JSPs keine Java-Kompilierung durchlaufen sollen.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -compile false
Anwendungsfall: Wenn Sie nur die Syntax von JSPs überprüfen möchten, setzen Sie -compile auf false. Sie können -keepgenerated auf true setzen, wenn Sie die .java-Dateien sehen möchten, die während der Umsetzungsphase generiert werden.
Standardeinstellung: true
- trackDependencies Gibt an, ob der Stapelcompiler eine JSP erneut kompiliert, wenn eine der abhängigen Dateien der JSP geändert wurden, auch wenn sich die JSP selbst nicht geändert hat. Die Überwachung von abhängigen Dateien führt zur Laufzeit zu einem erheblichen Durchsatzrückgang, da die JSP-Engine bei jeder Anforderung an eine JSP im Dateisystem überprüft, ob sich eine der abhängigen Dateien geändert hat. Folgende Abhängigkeiten werden von WebSphere Application Server überwacht:
- statisch in die JSP aufgenommene Dateien
- von der JSP verwendete Tag-Dateien (mit Ausnahme der in JAR-Dateien enthaltenen Tag-Dateien)
- von der JSP verwendete TLD-Dateien (mit Ausnahme der in JAR-Dateien enthaltenen TLD-Dateien)
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -trackDependencies true.
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -trackDependencies true.
Anwendungsfall: Dieser Parameter ist in einer Entwicklungsumgebung sinnvoll.
Standardeinstellung: false
- createDebugClassfiles
Gibt an, ob der Stapelcompiler Klassendateien mit SMAP-Informationen gemäß JSR 45, "Debugging Support for Other Languages", generiert.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -createDebugClassfiles true
Anwendungsfall: Verwenden Sie diesen Parameter, wenn Sie in Ihrer mit JSR 45 konformen IDE ein Debug für JSPs durchführen möchten.
Standardeinstellung: false
- keepgenerated
Gibt an, ob der Stapelcompiler die generierten Java-Quellendateien, die in der Übersetzungsphase erstellt wurden, speichert oder löscht.
Ist die Eigenschaft auf true gesetzt, speichert WebSphere Application Server die generierten .java-Dateien, die für die Kompilierung im Server verwendet werden. Standardmäßig ist dieses Argument auf false gesetzt, und die .java-Dateien werden nach der Kompilierung der Klassendateien gelöscht.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -keepgenerated true
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -keepgenerated true
Anwendungsfall: Verwenden Sie diesen Parameter, wenn Sie den vom Stapelcompiler generierten Java-Code überprüfen möchten.
Standardeinstellung: false
- keepGeneratedclassfiles
Gibt an, ob der Stapelcompiler die Klassendateien, die bei der Kompilierung der Java-Quellendateien generiert wurden, speichern oder löschen soll.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -keepGeneratedclassfiles false -keepgenerated false
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -keepGeneratedclassfiles false -keepgenerated false
Anwendungsfall: Setzen Sie diesen Parameter auf false, wenn Sie nur feststellen möchten, ob Umsetzungs- oder Kompilierungsfehler bei Ihren JSPs aufgetreten sind. Wird dieser Parameter zusammen mit -keepgenerated false verwendet, werden vor Beendigung des Stapelcompilers alle generierten Dateien entfernt.
Standardeinstellung: true
- usePageTagPool
Aktiviert oder inaktiviert die Wiederverwendung eines angepassten Tag-Handlers für einzelne JSPs.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -usePageTagPool true
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -usePageTagPool true
Anwendungsfall: Geben Sie diesen Parameter an, um die JSP-basierte Wiederverwendung von Tag-Handlern zu aktivieren.
Standardeinstellung: false
- useThreadTagPool
Aktiviert oder inaktiviert die Wiederverwendung eines angepassten Tag-Handlers für einzelne Anforderungsthreads pro Webmodul.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -useThreadTagPool true
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -useThreadTagPool true
Anwendungsfall: Geben Sie diesen Parameter an, um die webmodulbasierte Wiederverwendung von Tag-Handlern zu aktivieren.
Standardeinstellung: false
- classloader.parentFirst
Gibt die Suchreihenfolge für das Laden von Klassen an. Dieser Parameter weist den Stapelcompiler an, vor dem Klassenlader für Anwendungen nach dem übergeordneten Klassenlader gesucht wird. Dieser Parameter wird nur verwendet, wenn ear.path oder enterpriseApp.name angegeben ist.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -classloader.parentFirst false
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -classloader.parentFirst false
Anwendungsfall: Setzen Sie diesen Parameter auf false, wenn Ihr Webmodul eine JAR-Datei enthält, die auch im Serververzeichnis lib enthalten ist, und die JAR-Datei Ihres Webmoduls Vorrang haben soll.
Standardeinstellung: true
- classloader.singleWarClassloader
Gibt an, ob pro EAR-Datei bzw. pro WAR-Datei ein Klassenlader verwendet werden soll. Dieser Parameter wird nur verwendet, wenn ear.path oder enterpriseApp.name angegeben ist.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -classloader.singleWarClassloader true
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -classloader.singleWarClassloader true
Anwendungsfall: Setzen Sie diesen Parameter auf true, wenn ein Webmodul von JAR-Dateien und Klassen in einem anderen Webmodul derselben Unternehmensanwendung abhängig ist.
Standardeinstellung: false. Pro WAR-Datei wird ein Klassenlader erstellt, ohne Sichtbarkeit von Klassen in anderen Webmodulen.
- additional.classpath
Gibt zusätzliche Klassenpfadeinträge an, die bei der Syntaxanalyse und Kompilierung von JSPs verwendet werden sollen. Dieser Parameter wird nur verwendet, wenn war.path angegeben ist. Wenn war.path das Ziel ist, werden gemeinsam genutzte WebSphere-Bibliotheken nicht vom Stapelcompiler ausgewählt. Falls Ihre WAR-Datei beispielsweise von einer JAR-Datei abhängt, die in WebSphere Application Server als gemeinsam genutzte Bibliothek konfiguriert ist, verwenden Sie diese Option, um auf diese JAR-Datei zu verweisen. Wenn Sie war.path angeben und außerdem den Parameter -extractToDir verwenden, wird keine der im Klassenpfad des Manifests der WAR-Datei enthaltene JAR-Datei zum Klassenpfad hinzugefügt (da die WAR-Datei außerhalb der EAR-Datei, in der sie enthalten ist, extrahiert wurde). Verwenden Sie -additional.classpath in diesem Fall, um auf die nötigen JAR-Dateien zu zeigen. Fügen Sie den vollständigen Pfad zu den benötigten Ressourcen, die durch systemabhängige Trennzeichen voneinander abgetrennt werden, hinzu.
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -additional.classpath c:\myJars\someJar.jar;c:\myClasses
Beispiel: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -additional.classpath /home/wasuser/myJars/someJar.jar:/home/wasuser/myClasses
Anwendungsfall: Verwenden Sie diesen Parameter, um nicht in Ihrer WAR-Datei enthaltene JAR-Dateien und Klassen zum Klassenpfad hinzuzufügen. Zur Laufzeit müssen diese JAR-Dateien und Klassen von den Standardkonfigurationsmechanismen von WebSphere Application Server bereitgestellt werden.
Standardeinstellung: null
- verbose
Gibt an, ob der Stapelcompiler bei der Kompilierung der generierten Quellen eine ausführliche Ausgabe generieren soll.
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -verbose true
Beispiel: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -verbose true
Anwendungsfall: Setzen Sie diesen Parameter auf true, wenn Sie bei der Java-Kompilierung das Klassenladen und andere Nachrichten anzeigen möchten.
Standardeinstellung: false
- deprecation
Gibt an, dass der Compiler bei der Kompilierung der generierten Quellen Warnungen hinsichtlich veralteter Versionen ausgeben soll.
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -deprecation true
Beispiel: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -deprecation true
Anwendungsfall: Setzen Sie diesen Parameter auf true, wenn Sie bei der Java-Kompilierung Nachrichten zu veralteten Daten anzeigen möchten.
Standardeinstellung: false
- javaEncoding
Nennt die Codierung, die beim Generieren der .java-Datei verwendet werden soll, und gibt an, wann die Datei vom Java-Compiler kompiliert wird. Wenn -javaEncoding definiert ist, wird diese Codierung mit dem Argument -encoding an den Java-Compiler übergeben. Beachten Sie, dass encoding von Jikes nicht unterstützt wird.
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -javaEncoding Shift-JIS
Beispiel: JspBatchCompiler -war.path/home/wasuser/myproject/examples.war -javaEncoding Shift-JIS
Anwendungsfall: Setzen Sie diesen Parameter, wenn die Seitencodierung Ihrer JSPs nicht mit UTF-8 kompatibel ist.
Standardwert: UTF-8.
- jdkSourceLevel
Dieser Parameter der JSP-Engine wurde in WebSphere Application Server Version 6.1 für die Unterstützung von JDK 5 eingeführt. Verwenden Sie diesen Parameter anstelle des Parameters "compileWithAssert", obwohl "WithAssert" in Version 6.1 weiterhin funktioniert.
Der Standardwert für diesen Parameter ist "17". Dieser Parameter setzt voraus, dass die Java-Quelle erneut generiert wird. Im Folgenden sind die Werte für den Parameter jdkSourceLevel aufgelistet:- Der Wert 13 inaktiviert alle neuen Sprachenfunktionen von JDK 1.4, JDK 5.0, JDK 6.0, JDK 7.0 und JDK 8.0.
- Der Wert 14 aktiviert die Verwendung der Zusicherungsfunktion und inaktiviert alle neuen Sprachenfunktionen von JDK 5.0, JDK 6.0, JDK 7.0 und JDK 8.0.
- Der Wert 15 aktiviert die Verwendung der Zusicherungsfunktion und inaktiviert alle neuen Sprachenfunktionen von JDK 6.0, JDK 7.0 und JDK 8.0.
- Der Wert 16 aktiviert die Verwendung der Zusicherungsfunktion und inaktiviert alle neuen Sprachfunktionen von JDK 7.0 und 8.0.
- Der Wert 17 aktiviert die Verwendung der Zusicherungsfunktion und inaktiviert alle neuen Sprachenfunktionen von JDK 8.0.
- Der Wert 18 aktiviert die Verwendung der neuen Features von JDK 8.0.
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -jdkSourceLevel 14
Anwendungsfall: Setzen Sie diesen Parameter, wenn Sie die Sprachenfunktionen von JDK 1.4, JDK 5.0, JDK 6.0, JDK 7.0 und JDK 8.0 aktivieren oder inaktivieren möchten.
Standardwert: 17
- compilerOptions
Gibt eine Liste von Zeichenfolgen an, die an den Java-Kompilierungsbefehl übergeben werden sollen. Dabei handelt es sich um eine Liste des folgenden Formats, die Leerstellen als Trennzeichen verwendet: "arg1 arg2 argn".
Beispiel: JspBatchCompiler -war.path c:\myproject\examples.war -compilerOptions "-bootclasspath <Pfad>"
Beispiel: JspBatchCompiler -war.path /home/wasuser/myproject/examples.war -compilerOptions "-bootclasspath <Pfad>"
Anwendungsfall: Verwenden Sie diesen Parameter, falls andere Java-Compiler-Argumente als verbose, deprecation und Unterstützung für die Assert-Funktion erforderlich sind.
Standardeinstellung: null
- useJikes
Gibt an, ob Jikes für die Kompilierung von Java-Quellen verwendet wird. Anmerkung: Jikes ist nicht im Lieferumfang von WebSphere Application Server enthalten.
Beispiel: JspBatchCompiler -ear.path c:\myproject\sampleApp.ear -useJikes true
Beispiel: JspBatchCompiler -ear.path /home/wasuser/myproject/sampleApp.ear -useJikes true
Anwendungsfall: Setzen Sie diesen Parameter auf true, wenn der Stapelcompiler Jikes als Java-Compiler verwenden soll.
Standardwert: false
- jsp.file.extensions
Gibt die Dateierweiterungen an, die vom Stapelcompiler verarbeitet werden sollen. Die Bereitstellung erfolgt in Form einer Liste, die Semikola oder Doppelpunkte als Trennzeichen verwendet: *.ext1;*.ext2:*.extn. Für Servlet-2.4-Webanwendungen ist dieser Parameter nicht erforderlich, da die Erweiterungen, die als JSPs interpretiert werden sollen, mit der Eigenschaft url-pattern der Elemente jsp-property-group im Implementierungsdeskriptor festgestellt werden können.
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -jsp.file.extensions *jspz;*.jspt
Anwendungsfall: Verwenden Sie diesen Parameter, um Dateierweiterungen hinzuzufügen, die zusätzlich vom Stapelcompiler verarbeitet werden sollen.
Standardeinstellung: null. Weitere Informationen finden Sie im Abschnitt "JSP-Dateierweiterungen" in diesem Artikel.
- log.level
Gibt die Protokollstufe an, die bei der Stapelkompilierung an die Konsole geleitet wird. Gültige Werte: SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST | OFF
Beispiel: JspBatchCompiler -enterpriseApp.name sampleApp -log.level FINEST
Anwendungsfall: Steuern Sie die Protokollausgabe, indem Sie diesen Parameter auf eine höhere oder niedrigere Stufe setzen. Bei Angabe von FINEST wird eine für das Debug am besten geeignete Ausgabe generiert.
Standardeinstellung: CONFIG