Wenn man mit Java eine JAR-Datei ausführt, dann wird nicht die JAR-Datei ausgeführt, sondern der Java-Bytecode dieser JAR-Datei. Der Java-Bytecode liegt aber nicht im Speicherort der JAR-Datei und somit können Referenzen wie bsp. new File("serverlog.txt"); nicht richtig gefunden werden, wenn man davon ausgegangen ist, dass in diesem Fall die Datei serverlog.txt im selben Ordner wie die ausgeführte JAR-Datei zu finden ist.

Man muss sich deshalb den zur Laufzeit gültigen Pfad der JAR-Datei holen. Für dieses Vorhaben habe ich mir eine eigene Methode geschrieben:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

  /**
   * Returns the path where the currently running JAR-file is located.
   * Example value: C:\MyProject\build\jar\
   * @return Path of the JAR-file
   */
  public static String getJarExecutionDirectory()
  {
    String jarFile = null;
    String jarDirectory = null;
    int cutFileSeperator = 0;
    int cutSemicolon = -1;
 
    jarFile = System.getProperty("java.class.path");
    // Cut seperators
    cutFileSeperator = jarFile.lastIndexOf(System.getProperty("file.separator"));
    jarDirectory = jarFile.substring(0, cutFileSeperator);
    // Cut semicolons
    cutSemicolon = jarDirectory.lastIndexOf(';');
    jarDirectory = jarDirectory.substring(cutSemicolon+1, jarDirectory.length());
 
    return jarDirectory+System.getProperty("file.separator");
  }

Diese Methode liefert aber nur den richtigen Ort, wenn man die JAR Datei über die Konsole (java -jar meinprojekt.jar) ausführt. Deswegen möchte ich anhand eines Beispiels noch einen zweiten, zuverlässigeren Weg aufzeigen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

    String propertiesFilePath = "client.properties";
    File propertiesFile = new File(propertiesFilePath);
 
    if (!propertiesFile.exists())
    {
      try
      {
        CodeSource codeSource = MainView.class.getProtectionDomain().getCodeSource();
        File jarFile = new File(codeSource.getLocation().toURI().getPath());
        String jarDir = jarFile.getParentFile().getPath();
        propertiesFile = new File(jarDir + System.getProperty("file.separator") + propertiesFilePath);
      }
      catch (Exception ex)
      {
      }
    }
 
    System.out.println(propertiesFile.getAbsolutePath());

Über System.getProperty kann Java bestimme Informationen über das System, auf welchem der aktuelle Java Sourcecode ausgeführt wird, liefern. Zum Anzeigen des Benutzerverzeichnisses würde folgender Code ausreichen:

1
2

String userDirectory = System.getProperty("user.home");
System.out.println(userDirectory);

Die Ausgabe wäre in meinem Fall:

C:\Users\bennyn

Folgende System Properties sind verfügbar:

…weiterlesen

In meinem Beitrag NetBeans IDE mit Android SDK habe ich erklärt, wie man das Android SDK in der NetBeans IDE benutzen kann und ein wie man ein Android Virtual Device (AVD) einrichtet. Nun möchte ich darauf zu sprechen kommen, wie man eine SD-Speicherkarte emulieren kann.

…weiterlesen

Standardmäßig startet der GlassFish Application Server auf Port 8080. Die Adresse einer Webseite wird von einem Internet-Browser aus aber versucht auf Port 80 zu erreichen. Deshalb kann es von Vorteil sein, wenn man den GlassFish Server auf Port 80 setzt.

Dazu muss man in der GlassFish Konfigurationsdatei “glassfish/domains/domain1/config/domain.xml” folgenden Eintrag ändern:

Vorher:

<network-listener port="8080" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />

Nachher:

<network-listener port="80" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />

Atlassian FishEye ist ein besonders cooles Tool, um seinen Projekt-Sourcecode direkt in seinen JIRA-Projekten angezeigt zu bekommen. Völlig faszinierend finde ich, das man eine wunderbare Diff-Übersicht hat und Links zu einzelnen Codezeilen verschicken kann. Aus diesem Grund habe ich mich dafür entschieden, selbst FishEye für meine Git-Repositories in Zusammenhang mit JIRA einzusetzen. Wie ich es installiert habe, erfahrt ihr hier.

…weiterlesen

Auf der Suche nach dem richtigen Weg, um log4j in einem Java-Projekt zu integrieren, bin ich einen großen Umweg über haufenweise Blog-Artikel mit unvollständigen Konfigurationen und falschen Angaben gegangen, bis ich letztendlich bei diesem Video angekommen bin:

Obwohl dieses Video weder auf Deutsch noch auf Englisch ist, hat es mir in genau in 2 Minuten (!) weiterhelfen können, so dass ich jetzt ein dateibasiertes Logging mit log4j in meinem Projekt habe. Mehr wollte ich gar nicht. Das Durchstöbern von diversen Blogs hat mich über 1 Stunde Zeit gekostet, die nicht nötig gewesen wäre, wenn mal jemand auf die Idee gekommen wäre, das Thema durchschaubar und nicht umständlich und überladen zu beschreiben. Immerhin ist die Einbindung von log4j eine einfache Aufgabe!

Mein Anruf an alle Blogger dieser Welt: Bemüht euch vollständige Lösungen zu schreiben! Danke.

Hier meine Kurzbeschreibung für die Verwendung von log4j in NetBeans 7.0:

…weiterlesen