1. Überblick
In diesem Artikel wird erläutert, was Java Web Start (JWS) ist, wie es auf dem Server konfiguriert wird und wie eine einfache Anwendung erstellt wird.
2. Einführung
JWS ist eine Laufzeitumgebung, die mit Java SE für den Webbrowser des Clients geliefert wird und seit der Java-Version 5 verfügbar ist.
Mit dem Herunterladen der JNLP-Dateien (auch als Java Network Launch Protocol bezeichnet) vom Webserver können wir in dieser Umgebung JAR-Pakete ferngesteuert ausführen.
Einfach ausgedrückt, der Mechanismus lädt und führt Java-Klassen auf einem Client-Computer mit einer regulären JRE-Installation aus. Es erlaubt auch einige zusätzliche Anweisungen von Java EE. Sicherheitsbeschränkungen werden jedoch von der JRE des Kunden streng angewendet. In der Regel werden Benutzer vor nicht vertrauenswürdigen Domänen, fehlendem HTTPS und sogar nicht signierten JARs gewarnt.
Von einer generischen Website kann man eine JNLP-Datei herunterladen, um eine JWS-Anwendung auszuführen. Nach dem Download kann es direkt von einer Desktop-Verknüpfung oder dem Java Cache Viewer ausgeführt werden. Danach werden JAR-Dateien heruntergeladen und ausgeführt.
Dieser Mechanismus kann sehr hilfreich sein, um eine grafische Benutzeroberfläche bereitzustellen, die nicht webbasiert ist (HTML-frei), z. B. eine sichere Dateiübertragungsanwendung, ein wissenschaftlicher Rechner, eine sichere Tastatur, ein lokaler Bildbrowser usw.
3. Eine einfache JNLP-Anwendung
Ein guter Ansatz ist, eine Anwendung zu schreiben und sie in eine WAR-Datei für normale Webserver zu packen. Alles, was wir brauchen, ist, unsere gewünschte Anwendung (normalerweise mit Swing) zu schreiben und in eine JAR-Datei zu packen. Diese JAR muss dann zusammen mit einem JNLP in eine WAR-Datei gepackt werden, die normalerweise die Main -Klasse ihrer Anwendung referenziert, herunterlädt und ausführt.
Es gibt keinen Unterschied zu einer normalen Webanwendung, die in einer WAR-Datei gepackt ist, außer dass wir eine JNLP-Datei benötigen, um die JWS zu aktivieren.
3.1. Java-Anwendung
Beginnen wir mit dem Schreiben einer einfachen Java-Anwendung:
public class Hello {
public static void main(String[]args) {
JFrame f = new JFrame("main");
f.setSize(200, 100);
f.setLocationRelativeTo(null);
f.setDefaultCloseOperation(JFrame.EXIT__ON__CLOSE);
JLabel label = new JLabel("Hello World");
f.add(label);
f.setVisible(true);
}
}Wir können sehen, dass dies eine ziemlich einfache Swing-Klasse ist. In der Tat wurde nichts hinzugefügt, um es JWS-kompatibel zu machen.
3.2. Internetanwendung
Alles was wir brauchen, ist dieses JAR-Paket mit einer Swing-Klasse in eine WAR-Datei zusammen mit der folgenden JNLP-Datei zu packen:
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+"
codebase="http://localhost:8080/jnlp-example">
<information>
<title>Hello</title>
<vendor>Example</vendor>
</information>
<resources>
<j2se version="1.2+"/>
<jar href="hello.jar" main="true"/>
</resources>
<application-desc/>
</jnlp>Nennen wir es hello.jndl und legen Sie es in einen beliebigen Webordner unserer WAR.
Sowohl JAR als auch WAR können heruntergeladen werden, sodass wir uns keine Sorgen machen müssen, wenn Sie den JAR in einen lib -Ordner legen.
Die URL-Adresse für unsere endgültige JAR-Datei ist in der JNLP-Datei hartcodiert. Dies kann zu Verteilungsproblemen führen. Wenn wir die Deployment Server wechseln, funktioniert die Anwendung nicht mehr.
Beheben wir das mit einem richtigen Servlet weiter unten in diesem Artikel. Im Moment legen wir die JAR-Datei als index.html zum Download im Stammverzeichnis ab und verknüpfen sie mit einem Ankerelement:
<a href="hello.jnlp">Launch</a>-
Legen wir auch die Hauptklasse in unserem JAR-Manifest fest ** Dies kann durch Konfigurieren des JAR-Plugins in der Datei pom.xml erreicht werden. Ebenso verschieben wir die JAR-Datei außerhalb von WEB-INF/lib , da sie nur für den Download gedacht ist, d.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
...
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<archive>
<manifest>
<mainClass>
com.example.Hello
</mainClass>
</manifest>
</archive>
<outputDirectory>
${project.basedir}/target/jws
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>4. Sonderkonfigurationen
4.1. Sicherheitsprobleme
Um eine Anwendung auszuführen, müssen wir das JAR ** unterschreiben. Das Erstellen eines gültigen Zertifikats und das Verwenden des JAR Sign Maven Plugins geht über den Rahmen dieses Artikels hinaus. Wir können diese Sicherheitsrichtlinie jedoch zu Entwicklungszwecken umgehen oder wenn wir Administratorzugriff auf den Computer unseres Benutzers haben.
Dazu müssen wir die lokale URL hinzufügen (zum Beispiel:
http://localhost : 8080 ) zur Liste der Sicherheitsausnahmen der JRE-Installation auf dem Computer, auf dem die Anwendung ausgeführt wird. Sie finden es, indem Sie die Java-Systemsteuerung öffnen (unter Windows finden Sie es über die Systemsteuerung) auf der Registerkarte Sicherheit.
5. Das JnlpDownloadServlet
5.1. Kompressionsalgorithmen
Es gibt ein spezielles Servlet, das in unserem WAR enthalten sein kann. Es optimiert den Download, indem es nach der am stärksten komprimierten kompilierten Version unserer JAR-Datei sucht, sofern verfügbar, und außerdem den hart codierten codebase -Wert in der JLNP-Datei korrigiert.
Da unsere JAR-Datei zum Download zur Verfügung steht, ist es ratsam, sie mit einem Kompressionsalgorithmus wie Pack200 zu packen und die reguläre JAR-Datei sowie eine beliebige JAR.PACK.GZ- oder JAR.GZ-komprimierte Version im selben Ordner bereitzustellen, damit dieses Servlet dies kann Wählen Sie für jeden Fall die beste Option.
Leider gibt es noch keine stabile Version eines Maven-Plugins für diesen Kompressionsalgorithmus. Wir arbeiten jedoch mit der ausführbaren Pack200-Datei, die mit der JRE geliefert wird (normalerweise unter dem Pfad \ {JAVA SDK HOME}/jre/bin/ ).
Ohne unser JNLP zu ändern und die Versionen der JAR-Versionen jar.gz und jar.pack.gz im selben Ordner abzulegen, wählt das Servlet die bessere aus, sobald ein Anruf von einem Remote-JNLP erhalten wird. Dies verbessert die Benutzererfahrung und optimiert den Netzwerkverkehr.
5.2. Codebase Dynamische Ersetzung
Das Servlet kann auch dynamische Ersetzungen für hartcodierte URLs im Tag <jnlp spec = "1.0" codebase = "http://localhost: 8080/jnlp-example"> durchführen. Durch Ändern des JNLP in den Platzhalter <jnlp spec = ”1.0” codebase = ”$$ context”> wird das gleiche endgültige gerenderte Tag bereitgestellt.
Das Servlet funktioniert auch mit den Platzhaltern codebase__, __ hostname , name__ und __ site , wodurch „ http://localhost : 8080/jnlp-example/ “, “,“ Hello.jnlp “und“ http://localhost : 8080 ”.
5.3. Servlet zum Classpath hinzufügen
Um das Servlet hinzuzufügen, konfigurieren wir eine normale Servlet-Zuordnung für JAR- und JNLP-Muster in unserer web.xml :
<servlet>
<servlet-name>JnlpDownloadServlet</servlet-name>
<servlet-class>
jnlp.sample.servlet.JnlpDownloadServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JnlpDownloadServlet</servlet-name>
<url-pattern>** .jar</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>JnlpDownloadServlet</servlet-name>
<url-pattern>** .jnlp</url-pattern>
</servlet-mapping>Das Servlet selbst ist in einer Reihe von JARs ( jardiff.jar und jnlp-servlet.jar ) enthalten, die sich heute auf den Demos befinden
Im GitHub-Beispiel sind diese Dateien im Ordner java-core-samples-lib enthalten und werden vom Maven WAR-Plugin als Webressourcen enthalten:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
...
<configuration>
<webResources>
<resource>
<directory>
${project.basedir}/java-core-samples-lib/ </directory>
<includes>
<include>** ** /** .jar</include>
</includes>
<targetPath>WEB-INF/lib</targetPath>
</resource>
</webResources>
</configuration>
</plugin>6. Abschließende Gedanken
Java Web Start ist ein Tool, das in (Intranet-) Umgebungen verwendet werden kann, in denen kein Anwendungsserver vorhanden ist. Auch für Anwendungen, die lokale Benutzerdateien bearbeiten müssen.
Eine Anwendung wird über ein einfaches Download-Protokoll an den Endbenutzer ausgeliefert, ohne zusätzliche Abhängigkeiten oder Konfigurationen, mit Ausnahme einiger Sicherheitsbedenken (HTTPS, signierte JAR usw.).
In Git Example steht der in diesem Artikel beschriebene vollständige Quellcode zum Download zur Verfügung. Wir können es direkt von GitHub auf ein Betriebssystem mit Tomcat und Apache Maven herunterladen. Nach dem Download müssen wir den Befehl mvn install aus dem Quellverzeichnis ausführen und die generierte jws.war -Datei aus dem target in den webapps -Ordner der Tomcat-Installation kopieren.
Danach können wir Tomcat wie gewohnt starten.
Bei einer Standardinstallation von Apache Tomcat ist das Beispiel unter der URL http://localhost : 8080/jws/index.html verfügbar.