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.
Tarlika Elisabeth Schmitz wrote: > 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
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?
> 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.
Tarlika Elisabeth Schmitz <inva...@invalid.invalid> writes:
> 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>".
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.
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?!
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.
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 :-(
Tarlika Elisabeth Schmitz wrote: >> 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.
Daniel Völkerts <dvoelke...@web.de> wrote: >> 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.
Nico Seessle <nsees...@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)
Bernd Eckenfels wrote: > 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?
Gruß, -- Daniel Völkerts "Irren ist menschlich, und noch menschlicher ist es, einem Computer die Schuld zu geben." - U
Daniel Völkerts <dvoelke...@web.de> wrote: > 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.
> 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.
>>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.
Tarlika Elisabeth Schmitz <inva...@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.
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.
> 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.
bye -- Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
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 <inva...@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.
