eigentlich ein Basic-Thema mit dem Pfad, aber ich komm gerade trotzdem nicht weiter.
Hab ne Swing-Anwendung, in der ich auf ein Dokument zugreifen möchte, dies verändern (Platzhalter ersetzt) und dann abspeichern. Mit Eclipse klappt das problemlos. Wenn ich in den Ordner gehe, in dem die executable jar liegt und sie mit java -jar app.jar aufrufe auch, nur wenn ich mit Doppelklick auf das Icon die Anwendung starte, wird die neue Datei nicht gespeichert.
Das jar-File liegt in einem Verzeichnis, darin ist auch der Ordner templates mit einer odt-Datei. Diese soll eingelesen und verändert und dann unter einem anderen Namen in einem Verzeichnis output gespeichert werden. Die Verzeichnisse templates und output liegen direkt neben dem jar-File, also im gleichen Verzeichnis.
Grob sieht das so aus:
hauptverzechnis
app.jar
templates
vorlage2.odt
output
tempfile.odt
Auf die Vorlage im Verzeicnis templates greife ich so zu: new File("./templates/vorlage2.odt")
Die veränderte Ausgabe hat diesen Pfad: File outFile = new File("./output/tempfile.odt");
Sind die Pfadangaben falsch? Die Anwendung sollte eigentlich auf die Dateien in den Ordnern neben dem jar-File zugreifen. Muss ich da noch was im Build Path eintragen? Kann mir wer nen Tipp geben?
Das ganze läuft mit den Bibliotheken von JODReports und soll dann eigentlich so in das Verzeicnis geschrieben werden: template.createDocument(data, new FileOutputStream(outFile));
data sind die Daten, die für die Platzhalter eingesetzt werden
template ist von der Klasse DocumentTemplate von JODReports und die Methode sollte eingetlich das neue Document erstellen.
Klappt ja auch, halt nur nicht, wenn ich die Anwendung über das Icon im Menü starte.
Betriebssystem ist Debian…
Na ja, ich bekomm nur ne java.lang.UnsupportedOperationException: The PRINT action is not supported on the current platform!
Weil ich hier auf dem Laptop nicht drucken kann (wird später woanders gedruckt). Aber das ist nicht so wichtig, das Drucken kommt ja auch erst nachdem die Ausgabedatei erstellt wurde. Ansonsten keine Fehlermeldungen.
EDIT: Aaaargh, ich glaub ich hab den Fehler gefunden :wut: Und zwar wird die Datei doch geschrieben, aber dann vermutlich schreibgeschützt und ich kann nicht drüber schreiben. (hüstel, peinlich). Hmm, vorhin hatte es aber tatsächlich überhaupt nix in den output-Ordner geschrieben. Jetzt geht es wenigstens beim ersten mal. Jetzt ist nur noch die Frage, wie ich den Schreibschutz der neuangelegten Datei wegkriege, weil ich diese eine Datei ja immer wieder überschreiben möchte. Oder vielleicht diese Datei nach dem Drucken wieder löschen…?
Tja, sorry für die ganze Aufregung wegen (fast) nichts…
Die Verzeichnisse templates und output liegen parallel zur jar im “Hauptverzeichnis”?
Dann sollte die Pfadangabe eigentlich passen. Das “./” sollte man auch weglassen können.
Wenn die JVM direkt aus diesem Verzeichnis heraus gestartet, wird dann dann funktionert es tatsächlich und wenn die jar per Doppelklick gestartet wird funktioniert es nicht?
Kann denn die Template Datei gelesen werden?
Kenne mich mit Debian nicht aus, aber ist an der Dateiverknüpfung etwas auffälliges zu erkennen?
Sorry, muss gerade erst mal mit anderen Problemen in Eclipse kämpfen. Wollte gerade an der Datei im Code was ändern, hab dann mit STRG + S speichern wollen, keine Ahnung, ob ich dabei aus Versehen eine falsche Taste neben dem S erwischt hatte, aber plötzlich war die Datei komplett geändert, also in der Version, wie ich sie gestern angelegt hatte (ins Projektverzeichnis reinkopiert). Alle Änderungen, die ich seit gestern gemacht hatte, sind verschwunden. Als ob die Datei wieder auf ihren Ursprung zurückgesetzt wurde. Ist das normal? Kann ich da was tun, um das wieder rückgängig zu machen? Muss jetzt erst mal schauen, ob ich noch ne Kopie der Datei habe, ansonsten nochmal die Änderungen reinschreiben, soweit ich das wieder hinkriege…
EDIT: OK, hat sich erledigt, war nur ne Verwechslung von Dateien…
Muss da jetzt erst mal wieder Ordnung reinbringen, dann meld ich mich nochmal…
machmal auch paar “Pfadausgaben” um zu sehen wo was ist
ein “ups vergessen” Fehler ist oft, dass “user.dir” ein anderes Verzeichniss ausgibt, abhängig davon ob man per Doppelklick startet, oder eine Kommandokonsole
abhängig von deinen Dabian Einstellungen startet eine Konsole vermutlich mit dem Linux Heimverzeichnis (~), z.B: /home/LOGIN/benutzer/
wenn du von dort aus die Anwendung startest: java -jar /path/to/app/app.jar dann ist “user.dir” eben /home/LOGIN/benutzer/
wenn du per Doppelklick startest, dann ist das “user.dir” eben das, wo das jar grad rumliegt… oder die Verknüpfung zu dem jar etc
ich habe mir unter Linux angewöhnt mit
File f = new File(codeSource.getLocation().toURI().getPath());
jardir = f.getParentFile().getPath();```
zu arbeiten, ab da kannst problemlos mit relativen Pfadangaben arbeiten, da der Startpunkt immer das Verzeichnis ist, wo auch physisch das jar rumliegt.
aber irgendwie bezweifle ich, dass es wirklich daran liegt.
Danke erstmal für eure Hilfe. Ich weiss noch nicht, ob ich da heute noch dazu komme, da mal aufzuräumen. Ist durch das Herumprobieren etwas unübersichtlich geworden. Vorher macht es keinen Sinn, da weiter zu testen, weil vorher mögliche und unnötige Fehlerquellen ausgeschlossen werden müssen.
[QUOTE=mla.rue;74568]machmal auch paar “Pfadausgaben” um zu sehen wo was ist
ein “ups vergessen” Fehler ist oft, dass “user.dir” ein anderes Verzeichniss ausgibt, abhängig davon ob man per Doppelklick startet, oder eine Kommandokonsole
abhängig von deinen Dabian Einstellungen startet eine Konsole vermutlich mit dem Linux Heimverzeichnis (~), z.B: /home/LOGIN/benutzer/
wenn du von dort aus die Anwendung startest: java -jar /path/to/app/app.jar dann ist “user.dir” eben /home/LOGIN/benutzer/
wenn du per Doppelklick startest, dann ist das “user.dir” eben das, wo das jar grad rumliegt… oder die Verknüpfung zu dem jar etc
ich habe mir unter Linux angewöhnt mit
File f = new File(codeSource.getLocation().toURI().getPath());
jardir = f.getParentFile().getPath();```
zu arbeiten, ab da kannst problemlos mit relativen Pfadangaben arbeiten, da der Startpunkt immer das Verzeichnis ist, wo auch physisch das jar rumliegt.
aber irgendwie bezweifle ich, dass es wirklich daran liegt.[/QUOTE]
Hallo und sorry, dass ich jetzt erst wieder hier bin...
Also, ich hab mal getestet und geschaut, unter welchen Aufrufen es funktioniert und was user.dir ausgibt.
Hab jetzt mal bei den Pfaden der Dateien das "./" weggelassen.
Ich hab sowohl im workspace von Eclipse die beiden Ordner templates und output, als auch in dem Verzeichnis, in dem nachher die executable jar-Datei liegt.
Das output-Verzeichnis muss vorhanden sein (wird nicht automatisch angelegt), sonst gibt es ne Fehlermeldung.
**1.) Über Eclipse**
Funktioniert
user.dir zeigt auf den workspace
dort liegen auch die beiden Ordner templates und output
**2.) Über Konsole**
a) ins Verzeichnis des jar gewechselt und das dann mit java -jar name.jar aufgerufen
Funktioniert
user.dir zeigt auf das Verzeichnis mit dem jar und den beiden Ordnern (diese liegen direkt neben dem jar-File)
b) vom home-Verzeichnis mit Pfad zum jar-File aufgerufen
Findet template nicht
user.dir zeigt nur auf das home-Verzeichnis
**3.) Klick auf Icon (Favouriten bei Gnome oder Anwendungen auf Desktop)**
Findet template nicht
user.dir zeigt nur auf das home-Verzeichnis
Wenn ich nun das oben gepostete Beispiel verwende und den Pfad zu den Dateien hinzufüge:
```CodeSource codeSource = CamiloApp.class.getProtectionDomain().getCodeSource();
File f = new File(codeSource.getLocation().toURI().getPath());
jardir = f.getParentFile().getPath();```
Dann klappt es bei allen Versuchen, egal von wo ich das jar aufrufe. Ich versteh zwar noch nicht so genau, was dort passiert, aber es liefert mir den richtigen Pfad zurück. Ist es richtig, dass ich den CodeSource von meiner Start-Klasse hole, oder ist es egal von welcher Klasse? Geht das nur bei Linux oder auch Windows?
OK, hab ich ja eigentlich auch selbst testen können, wenn ich die Klassen austausche und mir den Pfad dann auf der Konsole ausgebe. Vielen Dank nochmal für die Hilfe… Ich mach hier dann mal auf erledigt…
