30 December 2007

Spring 2.x - Dynamic language support

Seit der Version 2.0 unterstützt das Spring Framework dynamische Skriptsprachen wie JRuby, Groovy und BeanShell. Bezüglich JRuby und BeanShell kann ich an dieser Stelle nichts aussagen, da ich die beiden Sprachen nicht genauer kennen. Bezüglich Groovy und Spring hingegen möchte ich ein paar Worte verlieren.

In Groovy hat man die Möglichkeit sogenannte Groovy Skripte anzulegen, welche dann zur Laufzeit als Klasse kompiliert und ausgeführt wird. Diese Skripte ermöglichen gewisse Applikationslogik in Skripte auszulagern und Anpassungen diesen dann ohne erneutes kompilieren (durch den Entwickler oder den Buildrechner à la Continous Integration) durchführen zu können. Über die Nachteile (Einspielen von bösartigem Code, erhöhter Sicherheitsaufwand) dieser Variante möchte ich an dieser Stelle nicht weiter eingehen.

Im nachfolgenden Beispiel sieht man wie man in Spring 2.x (XSD Version, mit der alten DTD Version geht das nicht) ein Groovy Skript als Spring Bean bekannt macht. Mittels dem Attribut refresh-check-delay erhält man die Möglichkeit Spring mitzuteilen, in welchem Zeitinterval es das Groovy Skript auf Veränderungen testen soll. Dieser Mechanismus lässt sich laut Dokumentation auch ausschalten, indem man einen negativen Wert angibt.
<lang:groovy id="messenger" refresh-check-delay="5000"
script-source="classpath:Messenger.groovy">
<lang:property name="message" value="I Can Do The Frug" />
</lang:groovy>
Ein weiteres neues Feature ist die Spring inline dynamic language, welches es dem Entwickler ermöglicht direkt in der spring.xml Datei Groovy Code einzubetten.
<lang:groovy id="messenger">
<lang:inline-script>
package org.springframework.scripting.groovy;

import org.springframework.scripting.Messenger

class GroovyMessenger implements Messenger {

String message
}
</lang:inline-script>
<lang:property name="message" value="I Can Do The Frug" />
</lang:groovy>
Gemäss den Angaben von SpringSource (ehem. Interface21) kann der Einsatz von dynamischen Skriptsprachen in Zusammenhang mit Spring in nachfolgenden Punkten Sinn machen.
  • Scripted Spring MVC Controllers
  • Scripted Validators
Anmerkung: Die Codebeispiele sind alle aus der Spring Dokumentation (Spring 2.5) übernommen worden.

Debian packages

Debian packages werden wie folgt installiert: dpkg -i package-name.deb

Installierte Debian packages anzeigen: dpkg -l

Mittels grep kann die Ausgabe von dpkg eingeschränkt werden. Sucht man bspw. das Groovy Paket, so kann dies folgendermassen ermittelt werden. dpkg -l | grep groovy.

Mit dpkg -r package-name kann das installierte Paket wieder entfernt werden.

27 December 2007

Internationalisierung mit dem Spring Framework

Das Spring Framework bietet einen einfachen Mechanismus um Applikationen zu internationalisieren (I18N) ohne die sprachspezifischen Texte in den Sourcecode einbetten und somit bei Änderungen erneut kompilieren zu müssen. Mittels der Klasse ReloadableResourceBundleMessageSource können die sprachspezifischen Texte in Java Properties Dateien ausgelagert werden. Die Klasse bietet, wie es ihr Namen schon verspricht, das Erkennen von Änderungen, die zur Laufzeit in der Properties Datei gemacht werden, an die Applikation weiterzuleiten.

Als erstes benötigt man die angesprochene Properties Datei, in diesem Beispiel hat sie den Dateinamen meinePropertyDatei.properties und enthält zwei Properties namens login.username und login.password. Diese beiden Properties Einträge dienen bspw. als Textinhalte für Masken, auf welchen ein Login durchgeführt wird.
Nachfolgend sind zwei Properties Dateien abgebildet. Einmal die erwähnte meinePropertyDatei.properties, welche als Basis Datei dient und dann eine Property Datei namen meinePropertyDatei_DE.properties, welche Texte in deutscher Sprache beinhaltet. Wie dieser Postfix im Dateinamen durch Spring behandelt wird, möchte ich zu einem späteren Zeitpunkt in diesem Artikel erklären.

[meinePropertyDatei.properties]

1. login.username=Please enter your username
2. login.password=Please enter your password


[meinePropertyDatei_DE.properties]

1. login.username=Bitte geben Sie Ihren Benutzernamen ein
2. login.password=Bitte geben Sie Ihr Passwort ein


Um die Klasse ReloadableResourceBundleMessageSource in der eigenen Applikation via Spring verwenden zu können, muss diese im ApplicationContext vermerkt werden. Dabei gibt man den Dateinamen der Basis Properties Datei meinePropertyDatei.properties ohne Dateiendung (und ohne Postfix) an.

[spring.xml]

1. <bean id="messageSource"
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
2. <property name="basenames">
3. <list>
4. <value>meinePropertyDatei</value>
5. </list>
6. </property>
7. </bean>


Damit man nun aus der Applikation auf die Properties Datei bzw. deren Textinhalte zugreifen kann, muss man in der entsprechenden Klasse nur die Interfaceklasse MessageSourceAware implementieren.

[HibernateUserService.java]

1. public class HibernateUserService implements MessageSourceAware {
2.
3. private MessageSource messageSource;
4.
5. public void setMessageSource(MessageSource messageSource) {
6. this.messageSource = messageSource;
7. }
8.
9. public void printStuff() {
10. System.out.println("Username Text: "
+ messageSource.getMessage("login.username", null, null));
11. System.out.println("Password Text: "
+ messageSource.getMessage("login.password", null, null));
12. System.out.println("Deutscher Benutzername Text: "
+ messageSource.getMessage("login.username", null, Locale.GERMAN));
13. System.out.println("Deutscher Passwort Text: "
+ messageSource.getMessage("login.password", null, Locale.GERMAN));
14. }
15.}


Nun muss man die Klasse HibernateUserService nur noch dem Spring Context bekannt machen.

[spring.xml]

1. <bean name="userService"
class="ch.minsight.core.java.services.HibernateUserService" />


Wenn man nun das Bean userService via dem Spring Application Context anfordert wird die MessageSource automatisch in die Instanz von HibernateUserService implantiert. Dies nennt man ein sogenanntes 'Autowiring', da Spring automatisch erkennt, dass HibernateUserService eine MessageSource benötigt und somit das Bean mit der ID 'messageSource' übergibt. Wie man aus dem Java Sourcecode entnehmen kann, können die Texte unter Bekanntgabe der jeweiligen Locale, sprachabhängig ausgelesen werden.

24 December 2007

Groovy: Update 1.5.1 verfügbar

Am 21. Dezember - pünktlich als Weihnachtsgeschenk - kündigt Guillaume Laforge, der Groovy Projektleiter, die Verfügbarkeit des Bugfix Releases Groovy 1.5.1 an.
The Groovy development team and G2One are pleased to announce the
release of Groovy 1.5.1 -- a bug fix release for Groovy 1.5.

It fixes a few problems that were discovered after the release of Groovy 1.5.0.
In particular: a dead lock in the Groovy classloader, and a problem
with input streams with the Ant builder.
Also, a problem in highly concurrent setups on multi-processor
machines made Groovy run anormally slowly, and this new release also
fixes this problem and makes Groovy run much faster using the full
power of all the CPUs.
Groovy 1.5.1 kann hier heruntergeladen werden. Wie gewohnt kann nebst dem Source Code auch eine vorkompilierte Version, ein inoffizieller Windows Installer oder ein Debian Package heruntergeladen werden.

23 December 2007

TeamCity 3.0 - Ein weiteres kostenloses Continous Integration Tool steht zur Verfügung

Praktisch zur gleichen Zeit wie IntelliJ IDEA 7.0 veröffentlich wurde, haben die Entwickler von JetBrains das Continuous Integration Tool TeamCity 3.0 freigegeben. Bisher habe ich jeweils mit CruiseControl(.NET) in Projekten gearbeitet, bin aber seit dem Erwerb von IntelliJ IDEA 7.0 auf TeamCity aufmerksam geworden. Es wird in einer Professional und Enterprise Edition angeboten, wobei die erstere Version kostenlos ist und sich laut JetBrains für kleinere und mittlere Entwicklungsunternehmen eignet. In dieser Version können 20 Softwareprojekte parallel verwaltet werden. Ausserdem können maximal 20 Anwender in TeamCity festgelegt werden. Dies sind aber bereits die einzigen Einschränkungen, welche in der Professional Edition hingenommen werden müssen. Eine Auflistung aller Features von TeamCity findet man hier.

Im direkten Vergleich mit CruiseControl sticht einem die relativ simple und GUI-unterstützte Konfiguration ins Auge, welche ermöglicht, dass sich der Administrator nicht mit einem XML Konfigurationsdokument à la CruiseControl auseinandersetzen muss. Ferner steht für die gängigen IDEs ein Plug-in für TeamCity zur Verfügung, mit welchem man das Continous Integration Tool aus der Entwicklungsumgebung steuern kann.

TeamCity 3.0 ist als Windows Installer, Mac OS X und Linux Setup verfügbar, welches jeweils mit einem integrierten Apache Tomcat mitgeliefert wird. Alternativ steht einem ein Web Application Archive (WAR) für ein Deployment auf einem eigenständigen Application Server.

TeamCity 3.0 macht mir nach ersten kleinen Tests einen sehr ausgereiften Eindruck. Es macht richtiggehend Spass mit TeamCity zu arbeiten, da alles sehr einfach zu konfigurieren ist.

8 December 2007

Groovy 1.5 ist erschienen

Seit dem 08.12.2007 Groovy in der Version 1.5 als stabiler Release erhältlich. Einer der grossen Erweiterungen seit 1.0 ist die sogenannte Joint-Compilation von Groovy/Java Source Code. Dies ermöglicht es Groovy Abhängigkeiten in Java Klassen in einem Buildlauf (z.B. mit Ant) zu kompilieren. Weiter können nun auch GroovyTestCases mit JUnit 4.0 arbeiten. Die Release Notes sind wie immer in Jira von Codehaus zu finden.

Aktuell steht noch kein Windows Installer oder Ubuntu / Debian Paket zum Download bereit. Diese sollen aber in den kommenden Tagen nachgeliefert werden.

Offensichtlich scheint es sich bei diesem Release um den wahrscheinlich letzten Groovy 1.x Release zu handeln. Dies vermute ich, da die Releasekandidaten dieses 1.5 Releases allesamt die Versionsnummer 1.1 trugen. Ich vermute daher, dass die kommenden Erweiterungen von Groovy unter 2.x weitergeführt werden.

Nun kann man gespannt sein und darauf warten, dass Grails erstmals in einer stabilen 1.0 Version veröffentlicht wird.