Relative Pfade zur ini-Datei

[Maja Donner]

Hallo allerseits.

ich habe hier ein wenig rumgsucht und auch einen Beitrag zu Relativen Pfaden gefunden. Doch bezieht der sich auf images.

Was ich allerdings brauche, ist ein realtiver pfad zu meine Ini-Datei.

Ich habe ein Properties-Klasse benutzt, um gewisse Einstellungen zu laden:

InputStream inFile = getClass().getResourceAsStream("/data/gc.ini");
gcProp = new Properties();
gcProp.load(inFile);

Funkt alles wunderbar.
Doch wie speichere ich das nun in die Datei zurück?!?!

Das habe ich versucht:

URL filePath = getClass().getResource("/data/gc.ini");
File f = new File(filePath.getPath());
f.createNewFile();
OutputStreamWriter outFile = new OutputStreamWriter(new FileOutputStream(f));
Application.getGcProp().store(outFile, null);

Doch da reagiert er nicht auf den realtiven Pfad, sondern speichert unter C:/data/gc.ini

Wie muss das laufen, wenn ich nun das ganze mit wirklich realtiven Pfaden machen möchte.

 

[DocRandom]

Moin!

Vieleicht hilft das weiter

lg
DocRandom

 

[Wildcard]

Für Einstellungen aller Art würde ich den Java Preferences Store empfehlen.

 

[Maja Donner]

@DocRandom
Danke schön. ich werde da mal heute ausprobieren.

@Wildcard
Die Funktion: Application.getGCProp() gibt mir die Properties. Und wie Du siehst, möchte ich ja diese store(9 Funktion benutzten, doch erwartet diese eine Pfadangabe und die wollte ich schon realtiv haben. Daran knacke ich gerade.

 

[Wildcard]

Hat diese Anmerkung irgend etwas mit meiner Antwort zu tun? ???:L

 

[Maja Donner]

Hm... ok ich habe Properties=Preferences verstanden. Was meinst Du mit Preferences?

 

[Wildcard]

Java hat einen Preferences Store um ... Preferences abzulegen :bae:
Du musst dich also nicht selbst um die Persistierung und das Laden kümmern.

 

[Maja Donner]

Oh man ich wußte schon, dass es mutig war diesen Job anzunehmen. Ich habe nicht geglaubt, dass es so mutig war... *schiefes grinsen*
oki... ich google mal "Preferences Store" *bg*

 

[Maja Donner]

so... ok... nach einigem Testen... *Seuftzt*

ich befürchte, das ist alle nicht ganz so das, was gewünscht ist.

Zunächst Preferences:
ich glaube das ist hier der falsche Ansatz, da ich keine Default-Einstellungen laden möchte, sondern eine von Benutzer vorgegebene Änderung in die ini packen möchte. Auch wird mir von oben gesagt, dass ich die Informationen in eine lesbare INI-Datei packen soll.

Dann nochmal zu den Relativen Pfaden. Die muss ich endlich verstanden haben. Der gibt mir nämlich jedes Mal einfach nur MÜLL raus... *grummel* Auch habe ich die Galileo-Seite durchgelesen, aber irgendwie funkt das nicht so ganz...

Bitte habt Geduld mit mir, aber ich kann nicht was andere abliefern, was nicht verlangt wurde.

In meinem Eslispe 3.3 Projekt habe ich Unterordner wie "src", "META-INF" etc und "data". Im data-Ordner steht eine gc.ini aus der ich alle Properties lade (das klappt) und bei Änderung in diese Datei die geänderten Properties speichern soll. Bei dem Speichern allerdings bekomme ich aber nie den korrekten Pfad von der File und er speichert mir das jedes Mal wild ab.. da brauche ich bitte Hilfe. Wie komme ich da an diesen vermaledeiten Pfad?

 

[Maja Donner]

Hm... ich glaube meine Verständnisschwierigkeit liegt ganz wo anders... Hoffe ich zumindest.

Ich habe ein wenig getest, in dem ich einfach eine Datei relativ erstellt habe.

FileOutputStream out = new FileOutputStream("myfile.txt");
PrintStream p = new PrintStream( out );
p.println ("Kleine Kotzprobe");
p.close();

Starte ich das Programm aus Eclipse heraus, speichert er die Datei in C:\eclipse3-3

Exportiere ich das Programm mit einer Exe landet es auch wirklich in Ordner "GC" der die Exe enthällt. :autsch:

Ist das normal/gewollt/sinnvoll !?!?!?!
Um es mal anders auszudrücken: WIESO DASS DENN?

Wie bekomme ich den Rechner dazu, dass er immer ein und die Selbe File nimmt?

Dann habe ich festgestellt, dass durch das Exportieren der Unterordner "data" mit das Jar gepackt wird. Der sollte aber als Unterordner unter "GC" landen und das ungepackt. Wie bekomme ich dass denn jetzt wieder hin? Ich glaube ich stehe auf allen Bahnhofsscläuchen der Welt.

 

[Wildcard]

Eine Dateiangabe bezieht sich immer auf das aktuelle Arbeitsverzeichnis zum Programmstart (user.dir).
Angenommen deine jar liegt in
/home/me/someDirectory/myJar.jar
in der Shell befinde ich mich nun in
/home/me
ich starte das Programm mit java -jar someDirectory/myJar.jar
Dann gibt user.dir /home/me zurück.

 

[Maja Donner]

Argh... da hätte ich lange suchen können... *grummelt*

Den sinn dieser Handhabe werde ich aber nicht so ganz verstehen.

Dann eine andere Frage, die mir weiterhelfen würde: wie finde ich zur laufzeit heraus, wo sich meine ausführende GC.Exe befindet?

 

[Wildcard]

Den sinn dieser Handhabe werde ich aber nicht so ganz verstehen.

Naja... dann ist es gut das du kein Betriebssystem schreiben musst :wink:

Dann eine andere Frage, die mir weiterhelfen würde: wie finde ich zur laufzeit heraus, wo sich meine ausführende GC.Exe befindet?

In welcher Sprache wurde besagte exe denn geschrieben?

 

[Maja Donner]

@1: na ich hätte die Relativen Pfade in Realtion zur Exe gesetzt und eine Funktion dazugepackt, so dass man das user.dir auch so bekommt.

@2: die Exe wurde mit von Eclipse generiert. Also in Java

 

[Wildcard]

@1: na ich hätte die Relativen Pfade in Realtion zur Exe gesetzt und eine Funktion dazugepackt, so dass man das user.dir auch so bekommt.

Das ist aber nicht die Art wie Betriebssystem arbeiten. Ein relativer Pfad hat immer einer Bezugspunkt. Vom Betriebssystem interpretierte Pfade haben als Bezugspunkt das current directory, also das aktuelle Arbeitsverzeichnis.

@2: die Exe wurde mit von Eclipse generiert. Also in Java

Es gibt keine java exe Dateien weil Java kein natives Kompilat ist und exe sowieso Windows spezifisch sind.

 

[Maja Donner]

@2: Dann habe ich keine Ahnung in welcher Sprache das sein soll. Es ist die von Eclipse generierte Exe

 

[Wildcard]

Eclipse erstellt aber keine exe. Höchstens mit einem mir unbekannten Plugin.
Was willst du überhaupt mit einer exe?

 

[Maja Donner]

*tief durchatmen* Was ich will steht leider nicht zur Debatte... ich habe vorgaben von oben, an denen ich nciht rütteln kann.

Also... ich benutzte den "Eclipse Product export wizard" und der erstellt mir diese Exe. Und ich bräuchte - wenn das geht - den Pfad dieser Exe zur Laufzeit.

Zur not reicht auch der Pfad des erstellten Jars - zur Laufzeit

 

[Wildcard]

Dann finde raus welches Plugin diesen Export durchführt.
Handelt es sich nämlich um C/C++, dann solltest du den gesuchten Pfad in der main des C/C++ Programms übergeben bekommen (so meine ich mich zumindest zu erinnern).

 

[Maja Donner]

main von c++? Öhm. Also c++ kenne ich schon und eins kann ich Dir sagen, da ist nix mit main und c++.

Ich habe nur meine Eclipse-Umgebung (Java) und dort und genau dort - und nicht in irgendeiner c++.exe - möchte ich doch nur meine Datei zur Laufzeit finden und später überschreiben. Ist Java dazu wirklich nicht in der Lage !?!?!?! *kann es sich kaum vorstellen.*

Wie finde ich heraus welches plugin den Export durchgeführt hat?

 

[Wildcard]

Ich habe nur meine Eclipse-Umgebung (Java) und dort und genau dort - und nicht in irgendeiner c++.exe - möchte ich doch nur meine Datei zur Laufzeit finden und später überschreiben. Ist Java dazu wirklich nicht in der Lage !?!?!?! *kann es sich kaum vorstellen.*

Du startest aber nicht die VM, sondern irgendeine Hinterwäldler-exe welche dann die Vm startet. Woher soll die VM denn nun wissen wo diese exe rumdümpelt?

Wie finde ich heraus welches plugin den Export durchgeführt hat?

Du wirst das Plugin wohl installiert haben, denn in der Standarddistribution wirst du keine .exe exportieren können, sondern eben eine .jar.

 

[Maja Donner]

Also... ich komme nicht an den Code der Exe. Die wird mir nämlich von "Hinterwäldler"-Eclipse 3.3 generiert. *g* Und dieser Export wird via "Eclipse Product export wizard" gemacht, der bei meinen Download dabei war. Ich haben nur noch Callisto dazu installiert.

Aber es reicht mir auch vollkommen zur den absoluten Pfad der von eclipse generierten Jar zur Laufzeit zu bekommen. vielleicht konzetrieren wir uns darauf? Geht dass denn, oder ist das nicht drin?

 

[Wildcard]

Also... ich komme nicht an den Code der Exe. Die wird mir nämlich von "Hinterwäldler"-Eclipse 3.3 generiert. *g* Und dieser Export wird via "Eclipse Product export wizard" gemacht, der bei meinen Download dabei war. Ich haben nur noch Callisto dazu installiert.

Du hast Callisto(3.2) zu Europa (3.3) installiert? :lol:
Du benutzt den Eclipse Product export Wizard?
Heißt dass, das es sich um eine RCP bzw. Eclipse Distribution handelt?
Na das sind ja ganz neue Informationen. Über die Eclipse Konfiguration kannst du Installationspfad auslesen.

 

[Wildcard]

Nachtrag:
So bekommst du den Ort an dem dein Eclipse Product installiert ist

Platform.getInstallLocation()

 

[Maja Donner]

also... dass es eclipse 3.3 ist, habe ich schon um 12 Uhr gesagt *g* und das mit dem "Export Wizard" auch etwas früher. Gut, das mit dem RCP habe ich nicht für wichtig erachtet, weil ja eigentlich unabhängig sein dürfte, wie der Code aussieht... dachte ich...

boah... das ist einfach zu viel Stoff auf einmal, um alles unter einen Hut zu bekommen...

aber gut weiter im Text: (Auch wenn ich die Hälfte wieder falsch verstanden habe)
Wo genau finde ich die Eclipse Konfiguration? Und meinst doch jetzt nicht Entwicklungsumgebung selbst, oder? Das hilft mir doch nicht, das den Installationspfad herauszusuchen.
User A speichert den Packen unter C:\meinMist und führt es unter C: aus
User B speichert es unter D:\ichweißnichtwas\hier ab und führt es unter D:\ichweißnichtwas aus.
Und ich weiss immernoch nicht, wie der absolute Pfad meiner Datei ist, weil sich der relative Pfad ja immer (nach Deiner Aussage) nach dem Ort richtet, wo der User das gestartet hat.

Also. Im Code per Lauzeit herausfinden, wo sich meine Jar oder irgend eine Datei aus meinem Programm befindet. Geht das?

 

[Wildcard]

also... dass es eclipse 3.3 ist, habe ich schon um 12 Uhr gesagt *g* und das mit dem "Export Wizard" auch etwas früher. Gut, das mit dem RCP habe ich nicht für wichtig erachtet, weil ja eigentlich unabhängig sein dürfte, wie der Code aussieht... dachte ich...

Also es ist wohl ein riesen Unterschied ob du Eclipse 3.3 verwendest, oder eine Eclipse Distribution erstellst.
Nichts für ungut, aber bei dem Kenntnissstand den du bisher an den Tag gelegt hast, kam mir letzteres auch gar nicht in den Sinn.
Siehe oben, Platform.getInstallLocation().
Es macht deshalb einen riesen Unterschied, weil dir das Eclipse Framework ganz andere Möglichkeiten bietet als ein 'normales' Java Programm.

 

[Maja Donner]

Mein Kenntnisstand zu Java und Eclipse ist gleich 0 + Epsilon... Deshalb habe ich gehofft in den Anfängerfragen richtig zu sein. *g*

C++, Konzeptionierung, Softwareengeeniering, DirectX und OpenGL kann ich Dir zu 90% runterbeeten. Aber Java und Eclipse... *verzieht das Gesicht.*

Und RCP ist eine Vorgabe von oben mir der ich im Augenblick mehr als nur die Hände voll habe. Für mein Empfinden ist vielen so unglaublich umständlich... aber es ist mein Empfinden... *g*

ich schaue mal, was ich hieraus machen kann. Danke für die Geduld.

 

[Wildcard]

C++, Konzeptionierung, Softwareengeeniering,.. kann ich Dir zu 90% runterbeeten

Dann dürftest du dich recht schnell mit der Eclipse API und OSGi anfreunden, denn Eclipse ist an vielen Stellen ein Paradebeispiel bezüglich, Konzeption, Objektorientierung und Softwaredesign.
Am Anfang mag einem die Sache über den Kopf wachsen, da sehr fortschrittliche Konzepte zum einsatz kommen, aber du wirst dich bei der RCP/PlugIn Entwicklung sicherlich persönlich weiterentwickeln.
Das wichtigste dürfte es sein die Extension Points, und die IAdaptable Schnittstelle zu verstehen, der Rest geht dann beinahe von selbst :wink:
Wenn es noch Probleme gibt, sag bescheid.

 

[Maja Donner]

Na hoffe, sonst sehe ich hier ganz schön schwarz. Was mich am meisten fasziniert, dass ich an so banalen Dingen scheitere, wie z.b. einen Pfad zu finden... Das Layout-Gezompe ging ja recht schnell über die Bühne, aber das... *grummelt* wir werden halt sehen... *g* Es lebe dennoch C++! ich vermisse meinen heiß geliebten Polymorphismus... *schnüff*