Detaillierte Einführung in den automatischen Kompilierungsmechanismus von JSP

Detaillierte Einführung in den automatischen JSP-Kompilierungsmechanismus

Im Allgemeinen ist der automatische Erkennungsmechanismus von Jasper relativ einfach. Er basiert auf einem Hintergrundthread, der kontinuierlich erkennt, ob die letzte Änderungszeit der JSP-Datei und der kompilierten Klasse vorliegt Wenn die Datei identisch ist, wird davon ausgegangen, dass keine Änderung vorliegt. Wenn sie jedoch unterschiedlich ist, müssen sie neu kompiliert werden. Da die JSP des in Tomcat bereitgestellten Projekts möglicherweise andere Seiten oder andere JAR-Pakete einführt und es sich bei diesen Ressourcen möglicherweise um Remote-Ressourcen handelt, ist die tatsächliche Verarbeitung komplizierter. Es ist auch erforderlich, diese verschiedenen importierten Ressourcen zu durchlaufen und zu erkennen Es wurden Änderungen vorgenommen.

Das obige Bild ist ein schematisches Diagramm. Wir wissen, dass es in der Tomcat-Architektur vier Ebenen von Containern gibt: Engine, Host, Kontext und Wrapper, und die JSP-Kompilierung entspricht Auf der Wrapper-Ebene führt StandardWrapper kontinuierlich Aufgaben aus, um Jasper aufzurufen, und Jasper erkennt und überprüft kontinuierlich verschiedene lokale und Remote-Ressourcen. Sobald festgestellt wird, dass eine Neukompilierung erforderlich ist. Lesen Sie weiter, um zu erfahren, wie dies erreicht wird.

Zunächst benötigen Sie einen Hintergrundausführungsthread. In Tomcat gibt es einen speziellen Thread, um Hintergrundaufgaben verschiedener Container auszuführen Um die Methode „backgroundProcess“ zu überschreiben, muss „backgroundProcess“ in „StandardWrapper“ neu geschrieben werden. Diese Schnittstelle implementiert die Schnittstelle „PeriodicEventListener“. Die Erkennungslogik kann in dieser Methode realisiert werden.

Zweitens: Was ist die Grundlage für die Erkennung und Beurteilung einer Neukompilierung? Bei der Neukompilierung wird JSP in Java und dann wieder in eine Klasse umgewandelt. Die Bedingung, die diese Aktion auslöst, ist, dass die Neukompilierungsaktion ausgelöst wird, wenn wir eine bestimmte JSP-Datei ändern oder nachdem die durch eine bestimmte JSP-Datei eingeführten Ressourcen geändert wurden. Daher ist die beste Grundlage für die Beurteilung das zuletzt geänderte Attribut einer bestimmten JSP oder Ressource. Die normale Reihenfolge besteht darin, dass die JSP kompiliert wird, um eine Klassendatei zu generieren, und das zuletzt geänderte Attribut der Klassendatei auf das zuletzt geänderte Attribut gesetzt wird Zu diesem Zeitpunkt sind die zuletzt geänderten Attribute der beiden Dateien identisch. Wenn wir die JSP-Datei ändern und speichern, wird das zuletzt geänderte Attribut der JSP auf den aktuellen Zeitpunkt festgelegt ob eine Neukompilierung durchgeführt werden soll, indem das lastmodified-Attribut der beiden Dateien beurteilt wird. Nach der Neukompilierung werden die lastmodified-Attribute der JSP- und Klassendateien wieder auf den gleichen Wert gesetzt. Bei importierten Ressourcen wird das Lastmodified-Attribut der importierten Ressource während der letzten Kompilierung im Speicher beibehalten. Das Lastmodified-Attribut der importierten Ressource wird kontinuierlich abgerufen und mit dem entsprechenden Lastmodified-Attribut im Speicher verglichen. Es kann auch leicht beurteilt werden, ob eine Neukompilierung erfolgt ist erforderlich.

Wie erkennt man schließlich lokale bzw. Remote-Ressourcen? Für lokale Ressourcen kann die Klasse java.io.File verwendet werden, um das lastmodified-Attribut einer JSP-Datei oder anderer Dateien einfach zu lesen. Für Remote-Ressourcen wie JAR-Pakete ist die Verwendung von java.NET.URL sehr praktisch, um die Verarbeitung der im JAR enthaltenen Attribute zu erleichtern. Es enthält viele Protokolle wie Common JAR, File, FTP und andere Protokolle, die sehr bequem zu verwenden sind.

URL includeUrl = new URL("jar:http://hostname/third.jar!/");
URLConnection iuc = includeUrl.openConnection();
long includeLastModified = ((JarURLConnection) iuc).getJarEntry().getTime();

Es sind nur drei Schritte erforderlich, um das Lesen des Remote-JAR-Pakets abzuschließen und die letzte Änderungszeit zu erhalten. Natürlich unterstützt URL auch das Lesen lokaler Dateiressourcen und ist daher ein gutes abstraktes Objekt zum Lesen von Ressourcen. Die Verwaltung importierter Ressourcen in Tomcat verwendet URL als Operationsobjekt.

In diesem Abschnitt wird die Implementierung des automatischen Erkennungsmechanismus von Jasper erläutert. Der automatische Erkennungsmechanismus bringt eine gute Erfahrung für unsere Entwicklung. Wir müssen den JSP nicht selbst ändern und den Tomcat-Vorgang durchführen Wir erkennen regelmäßig Kompilierungsvorgänge durch Jasper.

Danke fürs Lesen, ich hoffe, es kann allen helfen