gradle tomcat plugin
1.0.0
Das Plugin bietet Bereitstellungsfunktionen von Webanwendungen für einen eingebetteten Tomcat -Webcontainer in einem bestimmten Gradle -Build. Es erweitert das Kriegs -Plugin. Derzeit werden die Tomcat -Versionen 6.0.x, 7.0.x, 8.0.x, 8.5.x und 9.0.x unterstützt.
Der typische Anwendungsfall für dieses Plugin besteht darin, die Bereitstellung während der Entwicklung zu unterstützen. Das Plugin ermöglicht eine schnelle Entwicklung von Webanwendungen aufgrund der schnellen Startzeiten des Containers. Gradle startet den eingebetteten Behälter im selben JVM. Derzeit kann der Container nicht als separates Verfahren gegossen werden. Dieses Plugin kann auch keine Kriegsdatei in einem Remote -Container bereitstellen. Wenn Sie nach dieser Funktion suchen, schauen Sie sich stattdessen das Cargo -Plugin an.
Um die Funktionalität des Plugins zu verwenden, müssen Sie das Binärartefakt zum Klassenpfad Ihres Build -Skripts hinzufügen und das Plugin anwenden.
Das Plugin -Glas muss im Klassenpfad Ihres Build -Skripts definiert werden. Es ist direkt im Gradle -Plugin -Portal erhältlich. Das folgende Code -Snippet zeigt ein Beispiel zum Abrufen:
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath ' com.bmuschko:gradle-tomcat-plugin:2.7.0 '
}
}Die JAR -Datei wird mit zwei Plugins ausgestattet:
| Plugin -Kennung | Hängt von | Typ | Beschreibung |
|---|---|---|---|
| com.bmuschko.tomcat-base | - - | Tomcatbaseplugin | Bietet Tomcat-benutzerdefinierte Task-Typen, Vorkonfigurationsklassenpfad. |
| com.bmuschko.tomcat | com.bmuschko.tomcat-base | Tomcatplugin | Bietet Aufgaben zum Starten und Stoppen eines eingebetteten Tomcat -Behälters und enthüllt die Erweiterung namens tomcat . |
Das com.bmuschko.tomcat -Plugin hilft Ihnen, schnell loszulegen. Wenn Sie bei den vorkonfigurierten Aufgaben in Ordnung sind, ist dies die bevorzugte Option. Die meisten Plugin -Benutzer entscheiden sich für diese Option. Um das Tomcat -Plugin zu verwenden, geben Sie den folgenden Code -Snippet in Ihr Build -Skript ein:
apply plugin: 'com.bmuschko.tomcat'
Wenn Sie Ihre Aufgaben voll und ganz die Kontrolle benötigen oder nicht mit den vorkonfigurierten Aufgaben ausgehen möchten, möchten Sie das Plugin com.bmuschko.tomcat-base verwenden. Dies kann der Fall sein, wenn Sie den Container ausschließlich für Funktionstests einrichten möchten. Der Nachteil ist, dass jede Aufgabe in Ihrem Build -Skript einzeln konfiguriert werden muss. Um das Tomcat -Basis -Plugin zu verwenden, geben Sie den folgenden Code -Snippet in Ihr Build -Skript ein:
apply plugin: 'com.bmuschko.tomcat-base'
Zusätzlich müssen die Tomcat -Laufzeitbibliotheken zum Konfigurations tomcat hinzugefügt werden. Derzeit werden die Tomcat -Versionen 6.0.x, 7.0.x, 8.0.x, 8.5.x und 9.0.x vom Plugin unterstützt. Stellen Sie sicher, dass Sie keine Tomcat -Bibliotheken verschiedener Versionen mischen.
Tomcat 6.0.x:
repositories {
mavenCentral()
}
dependencies {
def tomcatVersion = ' 6.0.51 '
tomcat " org.apache.tomcat:catalina: ${ tomcatVersion } " ,
" org.apache.tomcat:coyote: ${ tomcatVersion } " ,
" org.apache.tomcat:jasper: ${ tomcatVersion } "
}Tomcat 7.0.x:
repositories {
mavenCentral()
}
dependencies {
def tomcatVersion = ' 7.0.76 '
tomcat " org.apache.tomcat.embed:tomcat-embed-core: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-logging-juli: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-jasper: ${ tomcatVersion } "
}Tomcat 8.0.x:
repositories {
mavenCentral()
}
dependencies {
def tomcatVersion = ' 8.0.42 '
tomcat " org.apache.tomcat.embed:tomcat-embed-core: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-logging-juli: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-jasper: ${ tomcatVersion } "
}Tomcat 8.5.x:
Bitte beachten Sie, dass die Abhängigkeits tomcat-embed-logging-juli nur erforderlich ist, um die Containerprotokolle über LOG4J 1.x zu aktivieren (was von der Log4J-Community nicht mehr unterstützt wird). LOG4J 2.x kann für die Containerprotokolle verwendet werden, ohne zusätzliche Bibliotheken zu deklarieren.
repositories {
mavenCentral()
}
dependencies {
def tomcatVersion = ' 8.5.16 '
tomcat " org.apache.tomcat.embed:tomcat-embed-core: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-logging-juli:8.5.2 " ,
" org.apache.tomcat.embed:tomcat-embed-jasper: ${ tomcatVersion } "
}
tomcat {
httpProtocol = ' org.apache.coyote.http11.Http11Nio2Protocol '
ajpProtocol = ' org.apache.coyote.ajp.AjpNio2Protocol '
}Tomcat 9.0.x:
Bitte beachten Sie, dass die Abhängigkeits tomcat-embed-logging-juli nur erforderlich ist, um die Containerprotokolle über LOG4J 1.x zu aktivieren (was von der Log4J-Community nicht mehr unterstützt wird). LOG4J 2.x kann für die Containerprotokolle verwendet werden, ohne zusätzliche Bibliotheken zu deklarieren.
repositories {
mavenCentral()
}
dependencies {
def tomcatVersion = ' 9.0.1 '
tomcat " org.apache.tomcat.embed:tomcat-embed-core: ${ tomcatVersion } " ,
" org.apache.tomcat.embed:tomcat-embed-logging-juli:9.0.0.M6 " ,
" org.apache.tomcat.embed:tomcat-embed-jasper: ${ tomcatVersion } "
}
tomcat {
httpProtocol = ' org.apache.coyote.http11.Http11Nio2Protocol '
ajpProtocol = ' org.apache.coyote.ajp.AjpNio2Protocol '
} Das com.bmuschko.tomcat -Plugin definiert die folgenden Aufgaben außerhalb des Boxs:
| Aufgabenname | Hängt von | Typ | Beschreibung |
|---|---|---|---|
| Tomcatrun | - - | Tomcatrun | Startet eine Tomcat -Instanz und bereitet die explodierte Webanwendung bereit. |
| Tomcatrunwar | - - | Tomcatrunwar | Startet eine Tomcat -Instanz und setzt den Krieg ein. |
| Tomcatstop | - - | Tomcatstop | Stoppt die Tomcat -Instanz. |
| Tomcatjasper | - - | Tomcatjasper | FIRT den JSP -Compiler und verwandelt JSP -Seiten mit Jasper in Java -Quelle. |
Das Tomcat -Plugin verwendet das gleiche Layout wie das Kriegs -Plugin.
Das Tomcat -Plugin enthält die folgenden Eigenschaften durch die Erweiterung mit dem Namen tomcat :
httpPort : Der TCP -Port, auf den Tomcat auf HTTP -Anforderungen anhören sollte (Standardeinstellungen bis 8080 ).httpsPort : Der TCP -Port, auf den Tomcat auf HTTPS -Anfragen anhören sollte (Standardeinstellungen bis 8443 ).ajpPort : Der TCP -Port, auf den Tomcat auf AJP -Anfragen anhören soll (Standardeinstellungen bis 8009 ).stopPort : Der TCP -Port, auf dem Tomcat auf Administratoranfragen anhören soll (Standardeinstellungen bis 8081 ).stopKey : Der Schlüssel zum Übergeben an Tomcat, wenn Sie ihn auffordern, anzuhalten (Standardeinstellungen nach null ).contextPath : Der URL -Kontextpfad, unter dem die Webanwendung registriert wird (Standardname zum Kriegsname).enableSSL : Bestimmt, ob der HTTPS -Anschluss erstellt werden soll (Standardeinstellungen zu false ).daemon : Gibt an, ob der Tomcat -Server im Hintergrund ausgeführt wird. Wenn diese Aufgabe wahr ist, wird diese Aufgabe erledigt, sobald der Server begonnen hat. Wenn dies falsch ist, blockiert diese Aufgabe, bis der Tomcat -Server gestoppt wird (standardmäßig zu false ).keystoreFile : Die für SSL verwendete Keystore -Datei, falls aktiviert (standardmäßig wird ein Keystore generiert).httpProtocol : Der zu verwendende HTTP -Protokollklassenname (Standards an org.apache.coyote.http11.Http11Protocol ).httpsProtocol : Der zu verwendende HTTPS -Protokoll -Handler -Klasse -Name (Standards an org.apache.coyote.http11.Http11Protocol ).ajpProtocol : Der zu verwendende Name der AJP -Protokoll -Handlerklasse (Standardeinstellungen an org.apache.coyote.ajp.AjpProtocol ).users : Liste der Benutzer mit username , password und roles . Wird verwendet, um Tomcat mit einer grundlegenden Authentifizierung mit diesen Benutzern zu konfigurieren. Der folgende Beispielcode zeigt, wie Sie die Standard -HTTP/HTTPS -Ports ändern. Um SSL zu aktivieren, enableSSL wir die Eigenschaft auf true . Die Webanwendung ist unter dem Kontextpfad sample-app zugänglich.
tomcat {
httpPort = 8090
httpsPort = 8091
enableSSL = true
contextPath = ' sample-app '
users {
user {
username = ' user1 '
password = ' 123456 '
roles = [ ' developers ' , ' admin ' ]
}
user {
username = ' user2 '
password = ' abcdef '
roles = [ ' manager ' ]
}
}
}Darüber hinaus können Sie die folgenden optionalen Taskeigenschaften festlegen:
contextPath : Der URL -Kontextpfad Ihre Webanwendung wird unter (Standardname zum Kriegsnamen) registriert.webDefaultXml : Die Standard -Web.xml. Wenn keine Instanz von org.apache.catalina.servlets.DefaultServlet und org.apache.jasper.servlet.JspServlet definiert wird.additionalRuntimeResources : Definiert zusätzliche Laufzeitgläser oder Verzeichnisse, die von der Webanwendung nicht bereitgestellt werden.URIEncoding : Gibt die Zeichenkodierung an, mit der die URI-Bytes durch den HTTP-Anschluss dekodiert werden (Standardeinstellungen zu UTF-8 ).daemon : Gibt an, ob der Tomcat -Server im Hintergrund ausgeführt wird. Wenn diese Aufgabe wahr ist, wird diese Aufgabe erledigt, sobald der Server begonnen hat. Wenn dies falsch ist, blockiert diese Aufgabe, bis der Tomcat -Server gestoppt wird (standardmäßig zu false ).configFile : Der Pfad zum Tomcat-Kontext XML-Datei (Standardeinstellungen zu src/main/webapp/META-INF/context.xml für tomcatRun , standardmäßig zu META-INF/context.xml im Krieg für tomcatRunWar ).outputFile : Die Datei zum Schreiben von Tomcat -Protokollnachrichten an. Wenn die Datei bereits vorhanden ist, wird neue Nachrichten angehängt.reloadable : Kürzt das Kontext -Scannen, wenn Sie keine Kontextdatei verwenden (Standardeinstellungen an true ).keystorePass : Das für SSL zu verwendende Keystore -Kennwort, falls aktiviert.truststoreFile : Die für SSL zu verwendende TrustStore -Datei, falls aktiviert.truststorePass : Das für SSL zu verwendende TrustStore -Passwort, falls aktiviert.clientAuth : Die zu verwendende Einstellung von ClientAuth kann es sein, Werte können: true , false oder want (Standardeinstellungen zu false ). HINWEIS: keystoreFile und truststoreFile benötigen jeweils eine Instanz einer File -EG file("/path/my.file")
Im folgenden Beispielcode deklarieren wir eine benutzerdefinierte Kontextdatei für die Task tomcatRun .
tomcatRun . configFile = file( ' context.xml ' ) So konfigurieren Sie die Jasper -Compiler -Aufgabe, Sie können die folgenden Eigenschaften im jasper -Verschluss der tomcat -Erweiterung festlegen:
validateXml : Bestimmt, ob web.xml validiert werden soll (Standardeinstellungen nach null ).validateTld : Bestimmt, ob web.xml validiert werden soll (Standardeinstellungen nach null ).uriroot : Das Root -Verzeichnis der Webanwendung (Standardeinstellung zu src/main/webapp ).webXmlFragment : Die generierte Web XML -Fragmentdatei auf Ihre Datei web.xml .addWebXmlMappings : Fügen Sie automatisch das generierte Web XML -Fragment zur Datei web.xml hinzu. Achtung: Dies ändert die Datei web.xml im Projekt, nicht im Build -Verzeichnis.outputDir : Das Ausgabeverzeichnis Die kompilierte JSPs enden (Standardeinstellungen zum build/jasper ).classdebuginfo : Sollte die Klassendatei mit Debugging -Informationen zusammengestellt werden (Standardeinstellungen an true ).compiler : Mit welchem Compiler -Ant sollte JSP -Seiten kompilieren. Weitere Informationen finden Sie in der Ant -Dokumentation. Wenn der Wert nicht festgelegt ist, wird der Standard -Eclipse JDT Java Compiler verwendet, anstatt Ant zu verwenden. Kein Standardwert.compilerSourceVM : Welche JDK -Version sind die Quelldateien kompatibel (Standardeinstellungen bis 1.6 ).compilerTargetVM : Welche JDK -Version sind die generierten Dateien, mit denen kompatibel ist (Standardeinstellungen bis 1.6 ).poolingEnabled : Bestimmt, ob das Tag -Handler -Pooling aktiviert ist. Dies ist eine Kompilierungsoption. Es wird das Verhalten von JSPs, die bereits kompiliert wurden, nicht verändert (Standardeinstellungen an true ).errorOnUseBeanInvalidClassAttribute : Sollte Jasper einen Fehler ausgeben, wenn der Wert des Klassenattributs in einer UseBean -Aktion keine gültige Bean -Klasse ist (Standardeinstellungen für true ).genStringAsCharArray : Sollten Textzeichenfolgen als Char -Arrays generiert werden, um die Leistung in einigen Fällen zu verbessern (Standardeinstellungen zu false ).ieClassId : Der Klasse-ID-Wert, der an Internet Explorer gesendet wird, wenn <jsp:plugin> Tags verwendet werden (Standardeinstellungen an clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 ).javaEncoding : Java -Datei -Codierung zum Generieren von Java -Quelldateien (Standardeinstellungen an UTF8 ).trimSpaces : Sollten weiße Räume im Vorlagentext zwischen Aktionen oder Direktiven beschnitten werden (Standardpact to TrimSpaces.TRUE ).xpoweredBy : Bestimmt, ob das Response-Header von X-Botschaften durch generiertes Servlet hinzugefügt wird (Standardeinstellungen zu false ).tomcat {
jasper {
validateXml = true
webXmlFragment = file( " $w ebAppDir /WEB-INF/generated_web.xml " )
outputDir = file( " $w ebAppDir /WEB-INF/src " )
}
}Ich bekomme eine Kompilierungsausnahme, wenn ich einen JSP aufruft. Fehlt mir etwas?
Die Ausnahme, die Sie vielleicht sehen, ist wahrscheinlich ähnlich wie folgt: org.apache.jasper.JasperException: Unable to compile class for JSP . Tomcat 7.x und 8.x verlangen, dass Sie Eclipse ECJ 3.6.x in Ihrem der Klassenpfad haben. Diese Version der Abhängigkeit existiert jedoch in Maven Central nicht. Sie müssen diese Abhängigkeit herunterladen und in Ihr eigenes Repository einfügen oder ein Repository auf Ihrer lokalen Festplatte definieren, in dem Sie sie fallen lassen können. Hier ist ein Beispiel:
repositories {
flatDir name : ' localRepository ' , dirs : ' lib '
} Warum bekomme ich eine java.lang.ClassCastException auf javax.servlet.Servlet ?
Tomcat ist sehr empfindlich für mehrere Versionen der Abhängigkeiten javax.servlet:servlet-api und javax.servlet:jsp-api in seinem Klassenpfad. Standardmäßig werden sie bereits als transitive Abhängigkeiten der eingebetteten Tomcat -Bibliotheken gezogen. Die Ausnahme, die Sie vielleicht sehen, sieht ähnlich aus:
java.lang.ClassCastException: org.springframework.web.servlet.DispatcherServlet cannot be cast to javax.servlet.Servlet
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1062)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1010)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4935)
at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5262)
at org.apache.catalina.core.StandardContext$3.call(StandardContext.java:5257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Um dies zu beheben, stellen Sie sicher, dass Sie Ihre JSP- und Servlet -Modulabhängigkeiten mit dem von SCOPE providedCompile Umfang wie folgt definieren:
providedCompile ' javax.servlet:servlet-api:2.5 ' ,
' javax.servlet:jsp-api:2.0 'Wie kann ich das Debuggen von meinem Tomcat im Plugin abdebuggen?
Wenn Sie in der Lage sein möchten, Ihre Anwendung aus der Ferne zu debuggen, müssen Sie die folgenden JVM -Optionen in Ihrer Umgebungsvariablen GRADLE_OPTS festlegen, bevor Sie den Container starten. Die von Ihnen gewählte Portnummer liegt bei Ihnen.
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
Tomcat hört dann den angegebenen Port für eingehende Remote -Debugging -Verbindungen an. Wenn Sie den Container starten, sollten Sie die folgende Nachricht sehen:
Listening for transport dt_socket at address: 5005
Überprüfen Sie Ihre IDE -Dokumentation, wie Sie eine Verbindung zum Remote -Debugging -Port konfigurieren.
Mein Tomcat -Container muss eine JNDI -Datenquelle verwenden. Wie richte ich mein Projekt ein?
Erstens müssen Sie sicherstellen, dass Sie die Abhängigkeit von Verbindungspool mithilfe der tomcat -Konfiguration deklarieren.
Tomcat 6.0.x:
def tomcatVersion = ' 6.0.35 '
tomcat " org.apache.tomcat:dbcp: ${ tomcatVersion } "Weitere Informationen finden Sie unter Koordinaten zu Maven Central.
Spätere Versionen:
def tomcatVersion = ' 9.0.8 '
tomcat " org.apache.tomcat:tomcat-dbcp: ${ tomcatVersion } "Weitere Informationen finden Sie unter Koordinaten zu Maven Central.
Wenn Sie sich für die Standardeinstellungen entscheiden, platzieren Sie Ihren context.xml im Verzeichnis src/main/webapp/META-INF . Um einen benutzerdefinierten Speicherort festzulegen, können Sie das Convention Property configFile verwenden. Hier ist ein Beispiel, wie Sie es für die Aufgaben tomcatRun und tomcatRunWar einstellen können.
[tomcatRun, tomcatRunWar] * . configFile = file( ' context.xml ' )In der Tomcat -Dokumentation finden Sie eine Liste von Kontextattributen. Das folgende Beispiel zeigt, wie Sie eine MySQL JNDI -Datenquelle einrichten.
<? xml version = " 1.0 " encoding = " UTF-8 " ?>
< Context >
< Resource name = " jdbc/mydatabase "
auth = " Container "
type = " javax.sql.DataSource "
username = " superuser "
password = " secretpasswd "
driverClassName = " com.mysql.jdbc.Driver "
url = " jdbc:mysql://localhost:3306/mydb "
validationQuery = " select 1 "
maxActive = " 10 "
maxIdle = " 4 " />
</ Context >Wie verwende ich die Hotcode -Bereitstellung mit dem Plugin?
Das Plugin bietet außergewöhnliche Unterstützung für den Austausch von Byte-Code über die Eigenschaft reloadable . Standardmäßig wird diese Option herausgestellt, sodass Sie keine zusätzlichen Konfigurationsänderungen benötigen. Alles, was Sie tun müssen, ist eine laufende Instanz des von tomcatRun initiierten Containers zu haben. Starten Sie Ihren bevorzugten Editor, ändern Sie eine Produktionsquellendatei, speichern Sie sie und kompilieren Sie Ihre Quellen in einem anderen Terminal über gradle compileJava neu. Nach ein paar Sekunden wird der Kontext neu geladen und Sie sollten das Verhalten im Terminalfenster sehen, das den Container ausführt:
Reloading Context with name [/myapp] has started
Reloading Context with name [/myapp] is completed
Alternativ können Sie andere technologische Tauschtechnologien des Comymericial -Byte -Codes verwenden. Die Konfiguration ist normalerweise produktspezifisch. Weitere Informationen für Ihr Projekt finden Sie in der Dokumentation des Produkts. Der folgende Abschnitt beschreibt, wie Gradle und das Plugin mit JRebel eingerichtet werden. Laden Sie zunächst Jrebel herunter, installieren Sie es auf Ihrem Computer und richten Sie die Lizenz ein. Um JRebel zu sagen, welches Verzeichnis nach geändertem Byte -Code scannen soll, müssen Sie eine rebel.xml -Datei erstellen. Platzieren Sie in Ihrem Webmodul die Datei unter build/classes/main , damit sie vom Tomcat -Plugin geladen werden kann. Zum Erstellen der Konfiguration der Datei ist das Gradle Jrebel -Plugin nützlich. Es ist nicht erforderlich, das Plugin zu verwenden. Sie können sich auch entscheiden, die Konfiguration von Hand zu erstellen. Denken Sie daran, dass gradle clean die Datei löscht. Die Einrichtung von Jrebel in einem Multi-Modul-Projektszenario finden Sie in der Dokumentation. Das folgende Code -Snippet zeigt eine Beispiel rebel.xml -Datei.
<? xml version = " 1.0 " encoding = " UTF-8 " ?>
< application xmlns : xsi = " http://www.w3.org/2001/XMLSchema-instance " xmlns = " http://www.zeroturnaround.com "
xsi : schemaLocation = " http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd " >
< classpath >
< dir name = " /Users/ben/dev/projects/mywebproject/build/classes/main " >
</ dir >
</ classpath >
< web >
< link target = " / " >
< dir name = " /Users/ben/dev/projects/mywebproject/src/main/webapp " >
</ dir >
</ link >
</ web >
</ application > Bearbeiten Sie Ihr Gradle -Start -Skript und fügen Sie ihm die folgende Zeile hinzu, um Gradle zu sagen, dass sie den JRebel -Agenten verwenden soll. Bitte stellen Sie sicher, dass Sie die Umgebungsvariable REBEL_HOME festlegen, die auf Ihr JREBEL -Installationsverzeichnis hinweist.
JAVA_OPTS="-javaagent:$REBEL_HOME/jrebel.jar $JAVA_OPTS"
Beim Start Ihres Webmoduls mit gradle tomcatRun sollten Sie Informationen über die verwendete JRebel -Lizenz und die gescannten Verzeichnisse nach Änderungen anzeigen. Für unsere Beispiel rebel.xml -Datei würde dies so aussehen:
JRebel: Directory '/Users/ben/dev/projects/mywebproject/build/classes/main' will be monitored for changes.
JRebel: Directory '/Users/ben/dev/projects/mywebproject/src/main/webapp' will be monitored for changes.
Wenn eine Datei neu kompiliert wurde, zeigt Jrebel dies an, indem sie sie wie folgt an die Konsole schreibt:
JRebel: Reloading class 'de.muschko.web.controller.TestController'.
In Anbetracht der Integrationstests für In-Container-Integration im Rahmen meines Builds. Was muss getan werden?
Normalerweise werden Einheits- und Integrationstests durch Konvention getrennt gehalten. Eine Konvention könnte darin bestehen IntegrationTest die Testquelldateien unterschiedlich Test benennen. Auf diese Weise können Sie sie separat ausführen. Für die Ausführung der Integrationstests möchten Sie die Tomcat -Aufgabe als Daemon -Thread ausführen und nach Abschluss Ihrer Tests herunterfahren. Das folgende Beispiel zeigt, wie eine Gradle -Aufgabe eingerichtet wird, die diese Funktionalität liefert. Natürlich ist dies nur eine Möglichkeit, es zu tun. Das folgende Beispiel erfordert Gradle> = 1.7:
apply plugin : ' com.bmuschko.tomcat-base '
ext {
tomcatStopPort = 8081
tomcatStopKey = ' stopKey '
}
task integrationTomcatRun( type : com.bmuschko.gradle.tomcat.tasks.TomcatRun ) {
stopPort = tomcatStopPort
stopKey = tomcatStopKey
daemon = true
}
task integrationTomcatStop( type : com.bmuschko.gradle.tomcat.tasks.TomcatStop ) {
stopPort = tomcatStopPort
stopKey = tomcatStopKey
}
task integrationTest( type : Test ) {
include ' **/*IntegrationTest.* '
dependsOn integrationTomcatRun
finalizedBy integrationTomcatStop
}
test {
exclude ' **/*IntegrationTest.* '
}Wie füge ich JAR -Dateien oder Verzeichnisse hinzu, die nicht Teil meines Webanwendungs -Quellcodes sind?
Jede Aufgabe des Typs AbstractTomcatRun enthüllt eine Eigenschaft mit dem Namen additionalRuntimeResources , die zum Mischen mit dem Webanwendungs -Laufzeitklassenpfad verwendet wird.
[tomcatRun, tomcatRunWar] . each { task ->
task . additionalRuntimeResources << file( ' /Users/bmuschko/config/props ' )
task . additionalRuntimeResources << file( ' /Users/bmuschko/ext/jars/my.jar ' )
}
