[WebStart] Deployment einer Anwendung in Linux Intranet
Tarlika Elisabeth Schmitz
Wir haben eine Anwendung, die auf allen Client PCs des Kunden zum
Einsatz kommen soll. Java WebStart scheint mir der ideale Kandidat für
Deployment, was m.E. Updates vereinfachen würde. Ich habe allerdings
noch einige Fragen offen:
Szenario:
Netzwerk bestehend aus einem Server und 6 Client PCs; Server Debian
Linux + Clients identisch pre-konfiguriert mit Debian Linux, Blackdown
Java 1.4.2.
Die Client PCs haben keinen FileSystem Zugriff auf den Server.
Die Anwendung wird auf lokale Image Dateien zugreifen. welche auf den
Server FTP'd werden.
Die Anwendung ist komplett in .jar Dateien organisiert.
Zielsetzung:
Die Anwendung soll per Desktop Icon gestartet werden. Es gibt zu einem
Zeitpunkt nur eine Version der Anwendung - alle Clients sollen das
letzte Update benutzen.
Der Anwender soll/braucht von WebStart nichts zu wissen; im Prinzip soll
einfach nur die aktuelle Version gestartet werden.
1) auf dem Server muß ein Web Server installiert sein, mit JNLP Mime Typ
konfiguriert (wir würden Apache einsetzen).
2) <???> Muß die Anwendung als WAR File deployed werden plus JNLP File,
oder können einfach die JAR Files der Anwendung in dem JNLP File
gelistet werden?
3) <???> Erstellung der Shortcuts?
Ich wäre dankbar über Erklärungen zu 2+3 u. was ich sonst noch übersehen
habe.
--
Regards/Gruß,
Tarlika Elisabeth Schmitz
Daniel Völkerts
> 1) auf dem Server muß ein Web Server installiert sein, mit JNLP Mime Typ
> konfiguriert (wir würden Apache einsetzen).
Jupp. Würde ich auch so machen.
> 2) <???> Muß die Anwendung als WAR File deployed werden plus JNLP File,
> oder können einfach die JAR Files der Anwendung in dem JNLP File
> gelistet werden?
Nein, WAR Files sind JAR für WEbapplikation die in einem
Servletcontainer (wie Tomcat) deployed werden. Imho sollte eine
Auflistung der Jar reichen um diese dann runterzuladen.
> 3) <???> Erstellung der Shortcuts?
Bei mir unter Windows fragt JWS ob ein Shortcut erstellt werden soll, ob
das unter Linux auch geht bleibt auszuprobieren ... Aber gibt es
überhaupt JWS bei Blackdown?
Gruß,
--
Daniel Völkerts
"Irren ist menschlich, und noch menschlicher ist es,
einem Computer die Schuld zu geben." - U
Nico Seessle
> Die Client PCs haben keinen FileSystem Zugriff auf den Server.
> Die Anwendung wird auf lokale Image Dateien zugreifen. welche auf den
> Server FTP'd werden.
Das hier verstehe ich jetzt nicht. Die Clients brauchen Image-Dateien
(Bilder nehme ich mal an?), die auf dem Server liegen, können aber nicht
drauf zugreifen?
> 1) auf dem Server muß ein Web Server installiert sein, mit JNLP Mime Typ
> konfiguriert (wir würden Apache einsetzen).
Bei einem Woody in der Firma kann ich mich nicht erinnern da was
geändert zu haben - werden aktuelle Apache-Versionen also evtl. schon
automatisch mit dabei haben.
> 2) <???> Muß die Anwendung als WAR File deployed werden plus JNLP File,
> oder können einfach die JAR Files der Anwendung in dem JNLP File
> gelistet werden?
Es reicht auch ein JNLP-File alleine. Mittels Server-seitiger Anwendung
ist es wohl möglich nur Teile der JARs (wenn eines sich geändert hat)
neu zu übertragen, wenn die aber klein genug sind und das Netz
ausreichend dimensioniert ist, dann lohnt sich evtl. der Aufwand nicht.
> 3) <???> Erstellung der Shortcuts?
Passiert - bei aktuellen Versionen von Webstart - automatisch auf
Rückfrage beim ersten Start. Java 5.0 bietet da wohl weitergehende
Möglichkeiten (Eintrag ins "Startmenü", etc.) soweit ich das gelesen
habe (habe ich aber nicht genutzt). Falls Bedarf besteht könntest du dir
auch den "JDIC Packager"
(https://jdic.dev.java.net/documentation/index.html#packager) für das
erstmalige Deployment der Anwendung anschauen, der kann dann wohl RPMs
für die erstmalige Installation erzeugen.
Nico
Ole Arndt
> 2) <???> Muß die Anwendung als WAR File deployed werden plus JNLP
> File, oder können einfach die JAR Files der Anwendung in dem JNLP
> File gelistet werden?
Das Deployment per WAR ist nur notwendig wenn die Anwendung über das
Java Webstart Servlet von Sun ausgeliefert wird. Das ermöglicht das
Update der Versionen über das sog. Jardiff Verfahren. Das lohnt sich
aber nur bei schmalbandiger Verbindung und wenn sich die Versionen
dauernd ändern.
> 3) <???> Erstellung der Shortcuts?
Javaws vom Blackdown JDK kann das, soweit ich mich erinnere auch für
KDE oder Gnome. Es langt aber auch ein einfaches Icon mit der
Kommandozeile: "javaws <jnlp-url>".
Ole
--
Ole Arndt http://www.sugarshark.com
Tarlika Elisabeth Schmitz
Nico Seessle wrote:
> Tarlika Elisabeth Schmitz wrote:
>
>> Die Client PCs haben keinen FileSystem Zugriff auf den Server.
>> Die Anwendung wird auf lokale Image Dateien zugreifen. welche auf den
>> Server FTP'd werden.
>
> Das hier verstehe ich jetzt nicht. Die Clients brauchen Image-Dateien
> (Bilder nehme ich mal an?), die auf dem Server liegen, können aber nicht
> drauf zugreifen?
Es ist weder Samba noch NFS installiert; Zugriff auf die Bilder nur
mittels der Anwendung.
>> 3) <???> Erstellung der Shortcuts?
>
> Passiert - bei aktuellen Versionen von Webstart - automatisch auf
> Rückfrage beim ersten Start. Java 5.0 bietet da wohl weitergehende
Wenn ich Sun's Dokumentation richtig verstehe, nur unter Windoze. Der
Shortcut enthält dann sowas wie
"C:\Program Files\Java\j2re1.4.2_01\javaws\javaws.exe" "@D:\User
Dir\Sun\Java\Deployment\javaws\cache\indirect\indirect13575.ind"
Das kann man wohl zur Not auch noch per Hand eintippen, wenn das mit
Blackdown nicht automatisch funktionieren sollte.
Tarlika Elisabeth Schmitz
Daniel Völkerts wrote:
> Tarlika Elisabeth Schmitz wrote:
>
> Nein, WAR Files sind JAR für WEbapplikation die in einem
> Servletcontainer (wie Tomcat) deployed werden. Imho sollte eine
> Auflistung der Jar reichen um diese dann runterzuladen.
>
>> 3) <???> Erstellung der Shortcuts?
>
> Bei mir unter Windows fragt JWS ob ein Shortcut erstellt werden soll, ob
> das unter Linux auch geht bleibt auszuprobieren ... Aber gibt es
> überhaupt JWS bei Blackdown?
Also, ein Executable names javaws ist da ;-)
Weißt Du etwas zu Folgendem:
<snip>
Laut Sun "Applications launched with Java Web Start software are -- by
default -- run in a restricted environment where they have limited
access to local computing resources, such as storage devices and the
local network. In this sandbox environment, ...."
</snip>
Wie schaut es also mit dem Zugriff auf lokale Dateien aus?!
Ortwin Glück
Tarlika Elisabeth Schmitz wrote:
> 2) <???> Muß die Anwendung als WAR File deployed werden plus JNLP File,
> oder können einfach die JAR Files der Anwendung in dem JNLP File
> gelistet werden?
Kommt drauf an. Muss nicht, aber kann! Wenn du das JNLP Servlet
verwenden willst, um JAR-Diffs zu benützen, dann ist ein WAR sicher gut.
Du kannst aber auch einfach das Namensschema für die Versionierung
verwenden. Dann brauchst du kein Servlet, JAR-Diffs gehen dann aber nicht.
Guck dir mal das an. Da findest du viel Infos zu Webstart:
http://www.vamphq.com/jwsfaq.html
Stefan Matthias Aust
> Wie schaut es also mit dem Zugriff auf lokale Dateien aus?!
Geht nicht (bzw. nur eingeschränkt über die Services) ohne die
Anwendungsjars mit einem gültigen oder selbstzertifizierten Zertifikat
zu signiernen.
bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Tarlika Elisabeth Schmitz
Stefan Matthias Aust wrote:
> Tarlika Elisabeth Schmitz schrieb:
>
>> Wie schaut es also mit dem Zugriff auf lokale Dateien aus?!
>
>
> Geht nicht (bzw. nur eingeschränkt über die Services) ohne die
> Anwendungsjars mit einem gültigen oder selbstzertifizierten Zertifikat
> zu signiernen.
>
D.h., jedes einzelne jar File muß signiert werden nach jedem Update?
Dann wird's lästig :-(
Johann Uhrmann
>> Geht nicht (bzw. nur eingeschränkt über die Services) ohne die
>> Anwendungsjars mit einem gültigen oder selbstzertifizierten Zertifikat
>> zu signiernen.
>
> D.h., jedes einzelne jar File muß signiert werden nach jedem Update?
> Dann wird's lästig :-(
>
Nicht unbedingt, mit einem Anttask kann man bequem ganze Stapel an
Jar-Files signieren.
Grüße,
Hans
Bernd Eckenfels
>> 1) auf dem Server muß ein Web Server installiert sein, mit JNLP Mime Typ
>> konfiguriert (wir würden Apache einsetzen).
>
> Jupp. Würde ich auch so machen.
Geschickter ist ein java web server fuer das jnlp servlet, weil man dann
z.b. jardiff nutzen kann.
> Nein, WAR Files sind JAR für WEbapplikation die in einem
> Servletcontainer (wie Tomcat) deployed werden. Imho sollte eine
> Auflistung der Jar reichen um diese dann runterzuladen.
Oder eben tomcat stattt apache und nur ein war.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Bernd Eckenfels
> Das hier verstehe ich jetzt nicht. Die Clients brauchen Image-Dateien
> (Bilder nehme ich mal an?), die auf dem Server liegen, können aber nicht
> drauf zugreifen?
die muessen im jar liegen das im war als ressource ist (oder man nutzt den
download service aber das is alles viel zu complex)
Stefan Matthias Aust
> D.h., jedes einzelne jar File muß signiert werden nach jedem Update?
> Dann wird's lästig :-(
Ja, und zwar mit dem selben key. Und nein, das kann man leicht
automatisieren.
Daniel Völkerts
> Geschickter ist ein java web server fuer das jnlp servlet, weil man dann
> z.b. jardiff nutzen kann.
Najo. In einem anderen Beitrag (von Nico? Bin grad zu faul zum
nachsehen) ging es darum das man die Diff Funktion nicht umbedingt
bräuchte wenn genug Bandbreite da ist und sich die Updates in Grenzen
halten.
> Oder eben tomcat stattt apache und nur ein war.
Äh? Wie jetzt. Ein War ist doch ein Webapp Archive (oder so). Ist doch
im Prinzip ein Zipfile genau wie ein Jar nur mit einer anderen
Dateistruktur (eben genau die man für eine Webapp braucht z.B. web.xml
etc.) Eine Jardatei mit einem Manifest sllte doch reichen oder?
Daniel Völkerts
[... mein Posting gesnippt ...]
Zu früh gepostet und zu spät gelesen. In dem Posting von dir Bernd und
von Ortwin wird deutlich wofür ein War benötigt wird.
Bernd Eckenfels
> Najo. In einem anderen Beitrag (von Nico? Bin grad zu faul zum
> nachsehen) ging es darum das man die Diff Funktion nicht umbedingt
> bräuchte wenn genug Bandbreite da ist und sich die Updates in Grenzen
> halten.
ja kann sein, aber normal haste ja auch oft nen java backend zum webstart
frontend, und da bietet sich halt tomcat oder jboss an, brauchst kein apache.
> Äh? Wie jetzt. Ein War ist doch ein Webapp Archive (oder so). Ist doch
> im Prinzip ein Zipfile genau wie ein Jar nur mit einer anderen
> Dateistruktur (eben genau die man für eine Webapp braucht z.B. web.xml
> etc.) Eine Jardatei mit einem Manifest sllte doch reichen oder?
Wenn deine webstart anwendung ein paar jars braucht das jnlp file und ne
webseite, dann kannste das alles in ein war packen und auf jedem web
container installieren stattt zig konfigurationen am apache machen zu
muessen. besonders wenn der ant prozess der war packt und deployed is das
nett. aber muss natuerlich nicht sein.
Bernd 'Nexos' Dutkowski
Noch was fuer das "Firts Deploy" hilft eventuel
https://jdic.dev.java.net/documentation/packager/example.html
bernd
Tarlika Elisabeth Schmitz
> Tarlika Elisabeth Schmitz schrieb:
>
>> D.h., jedes einzelne jar File muß signiert werden nach jedem Update?
>> Dann wird's lästig :-(
>
>
> Ja, und zwar mit dem selben key. Und nein, das kann man leicht
> automatisieren.
>
Danke, hab' gerade die SignJar Ant task entdeckt ...
Tarlika Elisabeth Schmitz
> Nico Seessle <nsee...@expires-2004-08-31.arcornews.de> wrote:
>
>>Das hier verstehe ich jetzt nicht. Die Clients brauchen Image-Dateien
>>(Bilder nehme ich mal an?), die auf dem Server liegen, können aber nicht
>>drauf zugreifen?
>
>
> die muessen im jar liegen das im war als ressource ist (oder man nutzt den
> download service aber das is alles viel zu complex)
>
Wenn ich das Posting von SMA richtig verstanden habe, ist File System
Zugriff (und FTP?) erlaubt, wenn alle JAR Files der Applikation signiert
sind.
Mit den Bilddateien hat es folgendes auf sich:
Die sind nicht Bestandteil der Anwendung, sondern es handelt sich dabei
um Anwender Daten. Im Klartext: der Benutzer macht Photos von seinen
Produkten. Die Anwendung ist eine DB-Anwendung mit DB auf dem Server.
Die Bilder werden auf den Server gebeamt und namentlich mit dem
jeweiligen Produkt assoziiert und sind über die Anwendung "ansehbar".
Die Bilder werden zudem für die [noch zu erstellende] Website benötigt.
Bernd Eckenfels
> Wenn ich das Posting von SMA richtig verstanden habe, ist File System
> Zugriff (und FTP?) erlaubt, wenn alle JAR Files der Applikation signiert
> sind.
Wenn du "all-permissions" anforderst dann ja. Das macht aber das sandbox
konzept von webstart zunichte.
Viel besser ist es meistens mit den WebStart API Services zu hantieren, z.b.
dem file choser mit dem der anwender sicher lokale files auswaehlen kann und
dir dann eine entsprechend eingeschraenkte web start anwendung lesen kann
ohne ne chance zu haben auf andere files zuzugreifen. Oder dem persitence
service um kleinere configurationen zwischenzuspeichern ohne gleich
schreibzugriff auf die platte zu benoetigen.
Stefan Matthias Aust
> Wenn du "all-permissions" anforderst dann ja. Das macht aber das sandbox
> konzept von webstart zunichte.
Das ist aber das einzige, was du bei Webstart kannst (oder irre ich
mich?) und ich finde daher das Prinzip ziemlich dumm.
> Viel besser ist es meistens mit den WebStart API Services zu hantieren
Falls deren beschränkte Möglichkeiten ausreichen. Leider kann man dann
auch nicht mehr eine Implementierung für normale Anwendung und Webstart
benutzen.
Tarlika Elisabeth Schmitz
ich muß zugegeben, daß ich noch nicht so ganz den Ueberblick über
WebStart habe. In erster Linie hatte ich WS als Convenience Möglichkeit
für einen bequemen Update der Anwendung beim Kunden: wir spielen eine
neue Verion remote auf deren Intranet Server, und deren Client PCs
kriegen automatisch die neue Version.
Bernd Eckenfels wrote:
> Tarlika Elisabeth Schmitz <inv...@invalid.invalid> wrote:
>
>>Wenn ich das Posting von SMA richtig verstanden habe, ist File System
>>Zugriff (und FTP?) erlaubt, wenn alle JAR Files der Applikation signiert
>>sind.
> Wenn du "all-permissions" anforderst dann ja. Das macht aber das sandbox
> konzept von webstart zunichte.
Du hast sicherlich recht, daß man nicht leichtfertig all-permissions
setzen sollte. Andererseits handelt es sich in diesem Fall um eine
kontrollierte Umgebung - es sind ja nicht irgendwelche User, die sich
das Programm vom Internet runterladen. Wenn ich das Programm nicht per
Web Start vom Server installieren würde, sondern "per Hand" auf jedem
Client, dann hätte die Applikation ja auch all-permissions.
Das Einzige, was die Anwendung auf lokalen Files machen soll, ist Datei
von HardDisk oder CF Card selektieren und Upload.
> Viel besser ist es meistens mit den WebStart API Services zu hantieren, z.b.
> dem file choser mit dem der anwender sicher lokale files auswaehlen kann und
> dir dann eine entsprechend eingeschraenkte web start anwendung lesen kann
Ich habe mir gerade mal kurz FileOpenService angesehen - wenn ich es
richtig verstehe, ermöglicht das im Wesentlichen eine Beschränkung auf
bestimmte Dateitypen.
Was das Abspeichern der [kleinen] Bilder auf dem Server angeht, könnten
diese statt auf dem Server FileSystem auch in der DB abgelegt werden.