Zunächst muss natürlich die VNC Freigabe in den Systemeinstellungen aktiviert werden:

Die ersten Versuche, mich mit TightVNC zu dem MacBook zu verbinden, schlugen mit der Fehlermeldung, dass die angeforderte Verschlüsselung nicht unterstützt wird, fehl. Diese Fehlermeldung ist recht irreführend, denn eine simple Einstellung unter Mac OS ist schuld. Es muss zwingend ein separates VNC Passwort festgelegt werden (nach erfolgreichem Verbindungsaufbau muss man sich noch einmal am System selbst anmelden), damit man sich per VNC verbinden kann:

Nachdem das Passwort festgelegt ist, sollte die Verbindung problemlos zustande kommen. Und ich bin wirklich überrascht, wie gut der VNC Server funktioniert: eine so schnelle VNC Verbindung habe ich bisher noch nicht erlebt. Selbst die Fensteranimationen laufen fast flüssig

Dazu lädt man zunächst die neuste Version des PuTTY Tunnel Managers von der Downloadseite herunter (ptman.exe) und wirft diese einfach in das Installationsverzeichnis von PuTTY. Nach dem Start des Tools erscheint ein neues Icon im System Tray.

Über dessen Kontextmenü können die Einstellungen des Programms sowie bereits in PuTTY eingerichtete SSH Tunnel aufgebaut werden:

In den Einstellungen können bequem neue Tunnel eingerichtet werden – und das wesentlich übersichtlicher als bei PuTTY selbst.

Über die Option Use PuTTY Tunnel Manager to store tunnels werden die eingerichteten Tunnel von PuTTY importiert und gleichzeitig aus PuTTY gelöscht, sodass PuTTY selbst keine Tunnel mehr aufbaut, sobald man sich mit einem entsprechenden Server verbindet.

Mit einem linken Mausklick auf das Icon können alle aufgebauten Tunnel übersichtlich dargestellt werden:

Insgesamt finde ich das Tool sehr gelungen und es landet nun definitiv in meiner dauerhaften Toolkiste

Zunächst wechselst du in das Verzeichnis /usr/lib:

cd /usr/lib

Danach kopierst du dir von der JRuby Downloadseite den Downloadlink der gewünschten JRuby Version im tar.gz Format in die Zwischenablage und lädst das Paket herunter:

wget <URL>

Das heruntergeladene Archiv wird nun entpackt und kann dann gelöscht werden:

tar xzf jruby-bin-<Version>.tar.gz
rm jruby-bin-<Version>.tar.gz

Jetzt müssen nurnoch JRuby Umgebungsvariablen eingerichtet werden. Öffne dazu die Datei /etc/environment mit einem Texteditor

nano /etc/environment

und erweitere zunächst den Path um folgende Angabe:

:/usr/lib/jruby-<Version>

Danach wird in der Datei noch die Umgebungsvariable JRUBY_HOME gesetzt:

JRUBY_HOME="/usr/lib/jruby-<Version>"

Abspeichern und fertig. Um die erfolgreiche Installation zu testen, muss sich nun einmal ab- und wieder angemeldet werden. Danach wird der Befehl

jruby -v

ausgeführt und sollte ein ähnliches Ergebnis liefern:

jruby 1.6.7.2 (ruby-1.8.7-p357) (2012-05-01 26e08ba) (OpenJDK 64-Bit Server VM 1.7.0_03) [linux-amd64-java]

Vor einiger Zeit habe ich bereits beschrieben, wie man Properties mit dem PropertySourcesPlaceholderConfigurer von Spring einbinden kann. Diesen Mechanismus kann man auch dafür nutzen, um SQL Queries auszulagern.

Als Ausgangsbasis dient folgende SQL Query, die – soweit wie möglich – lesbar formatiert im Quellcode untergebracht wurde:

public class InlineSQLExample {

	public User getUser() {

		final StringBuilder sqlBuilder = new StringBuilder();
		sql.append(" SELECT ");
		sql.append(" 	* ");
		sql.append(" FROM ");
		sql.append(" 	users ");
		sql.append(" WHERE ");
		sql.append(" 	username = :username AND ");
		sql.append(" 	password = :password ");
		final String sql = sqlBuilder.toString();

		// do some db stuff here
	}
}

Die Query schreibt man nun in eine ganz normale Properties Datei im XML Format und vergibt einen aussagekräftigen und gleichzeitig eindeutigen Schlüssel:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
	<comment>This comment is optional</comment>
	<entry key="getUserQuery">
		SELECT
			*
		FROM
			users
		WHERE
			username = :username AND
			password = :password
	</entry>
</properties>

Unter der Annahme, dass die Properties Datei mit GetUserQuery.xml benannt worden ist und auf oberster Ebene im Classpath liegt, können die Einträge (im Beispiel nur ein Eintrag) aus der Properties Datei wie folgt über die Spring Konfigurationsdatei verfügbar gemacht werden:

<bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
	<property name="location" value="classpath:GetUserQuery.xml" />
</bean>

Die Query kann dann über die Annotation @Value in die entsprechende Klasse eingesetzt werden. Das obige Beispiel sieht dann so aus:

public class OutsourcedSQLExample {

	@Value("${getUserQuery}")
	private String sql;

	public User getUser() {
		// do some db stuff here
	}
}

Die Vorteile liegen klar auf der Hand: die SQL Queries können unkompliziert bearbeitet und kopiert werden, ohne das StringBuilder.append() Gerüst drum herum bauen zu müssen. Außerdem steigt die Lesbarkeit und damit auch Wartbarkeit immens.

Thematisch werde ich hier in Zukunft wohl eher auf die Java Entwicklung eingehen, aber es werden auch hin und wieder andere Artikel eingestreut. Ich hoffe, ihr nimmt mir diesen drastischen Schritt nicht weiter übel, ich wollte dem Blog nur wieder etwas mehr Persönlichkeit einhauchen. Schon damals fanden einige, dass ich lieber auf www.patrick-gotthard.de hätte weitermachen sollen, ich hoffe, das hat sich nicht geändert

Solche JVM Shutdown Hooks sind sehr einfach zu implementieren. Es muss einfach ein Thread erzeugt werden, der als Shutdown Hook in die JVM eingebunden und automatisch beim Beenden der JVM ausgeführt wird.

Zur Erläuterung dient  folgendes, sehr einfaches Beispiel. Zunächst habe ich ein Runnable implementiert:

public class ShutdownHook implements Runnable {

	@Override
	public void run() {
		System.out.println("Called the shutdown hook!");
	}

}

Der Code innerhalb der run-Methode wird später automatisch beim Beenden der JVM ausgeführt. Dazu kommt dann noch eine Klasse zur Ausführung der Anwendung:

public class Main {

	public static void main(String[] args) {
		Thread shutdownHook = new Thread(new ShutdownHook());
		Runtime.getRuntime().addShutdownHook(shutdownHook);
	}

}

Aus dem Runnable wird hier zunächst ein Thread-Objekt erzeugt. Wer möchte, kann auch gleich bei der Implementierung des Shutdown Hooks von Thread ableiten, die Implementierung von Runnable ist aber in der Regel vorzuziehen. Danach wird der erzeugte Thread einfach bei der JVM als Shutdown Hook registriert und somit automatisch beim Beenden der JVM ausgeführt.

Shutdown Hooks sollten jedoch mit Bedacht eingesetzt werden. In einigen Situationen steht der JVM nur eine begrenzte Zeit zum Beenden zur Verfügung, z.B. wenn der Benutzer das System herunter fährt. Weitere Details findet man in der Java Dokumentation.

Quellen und weiterführende Links

• Offizielle Java Dokumentation zur addShutDownHook Methode

Zunächst benötigt man die entsprechende Derby Bibliothek. Bei Maven trägt man einfach folgende Abhängigkeit in die pom.xml ein:

<dependency>
	<groupId>org.apache.derby</groupId>
	<artifactId>derby</artifactId>
	<version>10.8.2.2</version>
</dependency>

Ansonsten lädt man sich von der Apache Derby Downloadseite das neuste lib-Paket herunter. In dem Paket sind mehrere jar Dateien enthalten, es wird daraus aber nur die derby.jar benötigt. Sobald die Bibliothek eingebunden ist, kann die Datenbank verwendet werden. Ich zeige nun eine simple Klasse, mit der man die Datenbank starten und stoppen kann, wobei beim ersten Start automatisch die Tabelle users angelegt wird.

package de.patrickgotthard.derbyapp;

import java.io.File;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class Database {

	private Connection connection;
	private final String database = "userdb";

	public void start() throws InstantiationException, IllegalAccessException, ClassNotFoundException, SQLException {
		Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
		if (new File(database).exists()) {
			connection = DriverManager.getConnection("jdbc:derby:" + database);
		} else {
			connection = DriverManager.getConnection("jdbc:derby:" + database + ";create=true");
			initTables();
		}
	}

	private void initTables() throws SQLException {
		connection.prepareStatement("CREATE TABLE users (username VARCHAR(50), password VARCHAR(32))").execute();
	}

	public void stop() {
		try {
			DriverManager.getConnection("jdbc:derby:" + database + ";shutdown=true");
		} catch (final Exception e) {
			e.printStackTrace();
		}
	}

}

Die Klasse sollte nun nach belieben für den eigenen Zweck angepasst werden. Ohne Persistenzframework wird natürlich die reine JDBC API verwendet.

Es soll nicht unerwähnt bleiben, dass laut Dokumentation beim Stoppen der Datenbank immer eine SQLException geworfen wird. Das ist vollkommen normal und kann ignoriert werden. Sollte eine Datenbank nicht korrekt gestoppt (zum Beispiel wenn man das Programm einfach abschießt) und dann wieder gestartet werden, startet die Datenbank einfach ein wenig langsamer, da Recovery-Routinen angestoßen werden.

Quellen und weiterführende Links

• Apache Derby Webseite
• Thorsten Horn – SQL mit Java

Bisher habe ich leider noch keine Zeit gefunden, mich einmal näher mit Scala auseinanderzusetzen. Dieses Vorhaben steht aber definitiv auf meiner TODO Liste. Hat jemand von euch schon einmal Erfahrungen mit Scala gemacht und kann einen kleinen Vergleich zu Java anstellen (wie gut ist z.B. die Dokumentation, wie schwer ist die Einarbeitung etc.)?

Quellen und weiterführende Links

• heise Developer - Scala 2.9.2 veröffentlicht
• Scala 2.9.2 Changelog
• Scala Webseite

Quellen und weiterführende Links

• heise Developer: Such-Engine: Apache Lucene und Solr in Version 3.6
• Apache Lucene Webseite

logback einbinden

Zunächst werden die Module logback-core und logback-classic benötigt. Bei Maven fügt man hierzu einfach folgende Abhängigkeit hinzu:

<dependency>
	<groupId>ch.qos.logback</groupId>
	<artifactId>logback-classic</artifactId>
	<version>1.0.1</version>
</dependency>

Ansonsten ist normalerweise keine spezielle Konfiguration notwendig. logback verwendet folgenden Initialisierungsprozess:

• suche nach logback.groovy im Classpath
• suche nach logback-test.xml im Classpath
• suche nach logback.xml im Classpath
• schreibe Logmeldungen in die Standardausgabe (Nutzung des DefaultConfigurers)

Sobald ein Kriterium (ausgenommen der Fallback Lösung am Ende) eintrifft, wird die entsprechende Konfigurationsdatei verwendet. Die Datei logback-test.xml nimmt eine kleine Sonderstellung ein. Wenn diese Datei bei der Verwendung von Maven in dem Ordner src/test/resources abgelegt wird, sorgt Maven dafür, dass diese Datei nicht mit in das Artefakt aufgenommen wird. Gleiches gilt laut Dokumentation analog für Ant. So können für die auszuliefernde Anwendung und für die Testdurchführung zwei unterschiedliche Konfigurationsdateien verwendet werden.

logback konfigurieren

Da das Logging in jedem Projekt sehr spezifische Anforderungen erfüllen muss, kann ich natürlich kein allumfassendes Musterbeispiel geben. Deshalb soll das folgende Beispiel nur als Einstieg für logback Neulinge dienen und dann mit Hilfe der logback Dokumentation an die jeweiligen Erfordernisse angepasst werden. Es zeigt die Konfiguration des oben angesprochenen DefaultConfigurers, der genutzt wird, falls keine Konfigurationsdatei gefunden werden konnte:

<configuration>

	<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
		<encoder>
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
		</encoder>
	</appender>

	<root level="debug">
		<appender-ref ref="STDOUT" />
	</root>

</configuration>

Hier wird zunächst ein ConsoleAppender namens STDOUT definiert. Der Formatierungsstring kann in folgende relevante Einzelteile zerlegt werden:

Danach wird der eben definierte Appender dem so genannten root Logger zugewiesen. Dieser greift immer dann, wenn keine speziellere Konfiguration für z.B. ein Package festgelegt wurde.

Dieses einfache Beispiel sollte nun für die gewünschten Logging Eigenschaften angepasst werden. So möchte man z.B. die Log Meldungen sowohl in eine (täglich wechselnde) Datei als auch auf die Standardausgabe schreiben und eine andere Formatierung verwenden. Hierfür nimmt man sich die excellente logback Dokumentation zur Hand.

logback nutzen

Folgend zeige ich eine beispielhafte Verwendung von logback. Man sollte darauf achten, nicht direkt die Klassen von logback, sondern die von der SLF4J API bereitgestellten Klassen zu nutzen. So kann später ohne Probleme auf ein anderes von SLF4J unterstütztes Logging Framework umgestellt werden.

package de.patrickgotthard.logback;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Main {

	private static final Logger LOG = LoggerFactory.getLogger(Main.class);

	public static void main(final String[] args) {
		LOG.debug("Starting application");
		try {
			throw new Exception("FooBar");
		} catch (final Exception e) {
			LOG.error("Starting the application failed", e);
		}
		LOG.debug("Closing application");
	}

}

Mit der eben gezeigten Standardkonfiguration erfolgt folgende Konsolenausgabe:

05:44:17 [main] DEBUG de.patrickgotthard.logback.Main - Starting application
05:44:17 [main] ERROR de.patrickgotthard.logback.Main - Starting the application failed
java.lang.Exception: FooBar
	at de.patrickgotthard.logback.Main.main(Main.java:13) ~[classes/:na]
05:44:17 [main] DEBUG de.patrickgotthard.logback.Main - Closing application

Ich denke, das sollte als Einstieg in logback zunächst einmal reichen. Schnapp dir die Dokumentation und schau selber, welche mächtigen Features logback sonst noch zu bieten hat