Migration Spring Integration 2.x to 3.x with Jackson2 and Joda DateTime

Until Spring Integration 3 finally introduced built-in support for Jackson2, you are probably sticked at Jackson 1 (1.6 or so) for messaging serialization, i.e. used for AMQP endpoints like RabbitMQ. That was even more ugly in web projects where the complete MVC stack was Jackson2 ready, but not the integration part. Even though that situation is unattractive, you could always deal with without hacking converters because Jackson 1 and 2 have completely different namespaces (because of the migration back from codehaus to the fasterxml domain).

That changes now with Spring Integration 3.

My personal check list when migrating:

  1. Ensure no Jackson 1.x is in the classpath anymore. Yes, check it again. There are sometimes these little annoying transitive dependencies. If so, the automatic/magic resolver (aka legacy compatibility code) of Spring Integration will prefer it. You can handle this with custom transformers, but not the built-in directives.
  2. Forget the new introduced MessageConverter in case of (AMQP) gateways, because it will not be used in the situation of message replies (INT-3285 which was actually a regression bug and will be fixed in 3.0.2).
  3. Know the existence of a Jackson’s ObjectMapper wrapper. Yes, really. The JsonObjectMapper can contain both Jackson1 and Jackson2 ObjectMappers.
  4. After point 3: If you want to customize the ObjectMapper (i.e. for a simple mapper.registerModule(new JodaModule());) you have to provide such a JsonObjectMapper. Easy with a small config.
  5. After point 4: Do not forget to add this custom ObjectMapper for each JSON transformer in use.

An example: [gist id=8825643 file=config.xml]

Updated 15.02.2014 adding reference to INT-3285

Updated 03.05.2014 INT-3285 resolved with release of Spring Integration 3.0.2

Can you trust your npm dependencies?

Maybe.

OS X 10.9 Mavericks: SourceTree funktioniert nicht mehr, kein Git-Svn mehr?

Auch nach einer manuellen Neuinstallation der MacPorts funktioniert Git-Svn und damit auch Tools wie SourceTree nicht mehr, weil Libraries (hier zu Perl) nicht mehr gefunden werden.

Temporäre Abhilfe verschaffen hier  zwei Symlinks.

sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/SVN /System/Library/Perl/Extras/5.16/SVN
sudo ln -s /Applications/Xcode.app/Contents/Developer/Library/Perl/5.16/darwin-thread-multi-2level/auto/SVN/ /System/Library/Perl/Extras/5.16/auto/SVN

OS X 10.9 Mavericks: Kostenloses iWorks Update für DVD-Kunden

Aktuell wird für Kunden, die die iWorks Suite noch von einem DVD-Datenträger installiert haben (und eben nicht via Mac App Store), kein kostenloses Update für Keynote, Pages und Numbers angeboten — zumindest in Deutschland.

Stellt man seine Systemsprache auf Englisch und bootet neu (vielleicht reicht auch aus- und einloggen), dann werden die kostenlosen Updates angeboten.

Danke für den Tipp!

Ach ja, übrigens: Weil das Upgrade durchaus Features weniger hat, empfiehlt sich unter Umständen ein Backup der alten Software. Prinzipiell sind die ja auch beide parallel lauffähig.

OS X 10.9 Mavericks: Kein M2_HOME mehr in IntelliJ IDEA

Nach dem Update auf Mavericks hat sich auch unter der Haube einiges an Libraries getan. So ist nicht nur das System-Ruby auf Version 2 angehoben worden, sondern auch Maven wurde nebst Java jetzt wirklich komplett entfernt.

Damit man in IntelliJ IDEA nicht in jedem Projekt separat die Maven-Konfiguration nachpflegen muss, muss man nun Maven auch selber installieen (musste man vorher auch, wenn man eine andere Version als den Default haben wollte). Leider erhalten GUI-Anwendungen unter OS X nicht einfach alle Umgebungsvariablen (aus dem Enviroment, ~/.bash_profile usw.). Seit 10.8 und 10.9 muss man wohl tatsächlich, will man globale Variablen anlegen, diese im Launch Daemon registrieren. Dies wiederum kann man aber bspw. in seiner ~/.bash_profile machen.

Das sieht bei mir nun wie folgt aus:

export M2_HOME=~/bin/apache-maven-3.0.5
export M2=$M2_HOME/bin
launchctl setenv M2_HOME $M2_HOME
launchctl setenv M2 $M2

Darüber hinaus schadet es auch nicht, eine funktionierende JAVA_HOME Variable anzulegen, weil manche stumpfsinnigen OSX-Anwendungen einfach nicht in der Lage sind ohne auszukommen:

export JAVA_HOME=$(/usr/libexec/java_home)
launchctl setenv JAVA_HOME $JAVA_HOME

Und wenn wir einmal dabei sind, aktualisieren wir noch den Pfad.

launchctl setenv PATH $PATH

Wahlweise kann man hier natürlich auch das $M2 hinzufügen ($PATH:$M2), wenn man den Befehl „mvn“ auch im Pfad haben will.

Proof Of Concept: Proxy-Download von S3

Aufgabe

Die Verwendung von Amazon S3 soll a) nicht öffentlich gemacht werden und/oder man b) möchte den Zugriff per zusätzlicher Authentifizierung absichern. Es gilt also, durch eine Anfrage per HTTP einen Download bei S3 anzustoßen und den Inhalt entsprechend zurückzuschreiben.

Option 1: Download auf Temp-File / Speicher

Zunächst kann man natürlich ganz allgemein den Download abstoßen, den Inhalt lokal auf dem Server in eine Datei packen und anschließend dem Client zurückzuschicken.

Problem 1: Selbst bei guter Anbindung des Servers an S3 muss man erst alles laden und erst bei Beendigung des Downloads kann man dem Benutzer die Datei schicken. Dieser Delay ist unschön.

Problem 2: Sollte die Datei größer sein, verbraucht man (unnötigerweise) Platz auf dem Server.

Problem 3: Eventuell ist es aus Sicherheitsgründen auch nicht wünschenswert.

Option 2: Download direkt auf Client speichern

Sobald der Download angestoßen wurde und Daten liefert, werden die Chunks (Buffer-Pakete) sofort dem Stream der laufenden HTTP-Anfrage rausgeschrieben. Damit wird sichergestellt, dass weder auf der lokalen Platte oder im Speicher des Servers unnötige Daten gespeichert werden müssen.

Code liegt bei GitHub, wo denn sonst.

Sonstiges

  • Die NodeJS Library knox setzt auf aws-sdk auf und bietet ein Wrapper um die AWS-S§-Response. Damit ist dies Lösung oben geringfügig einfacher zu realisieren.
  • Eine Alternative zu der ganzen Thematik können auch so genannte Signed URLs sein. Eine Signed URL auf S3-Content ermöglicht auch temporären Zugriff auf nicht öffentliche Dateien. Signed URLs sind relativ simpel, weil sie nur aus dem Expiry Date und einer Signatur (auf Basis des privaten Schlüssels des Owners) dessen bestehen.

Spring 3.2 + JodaTime + Jackson2

Möchte man in seinem frischen Spring 3.2 Projekt auch gerne Jackson 2 (Version 2 von fasterxml, Version 1.x bei codehaus) mit Joda Time verdrahten, um beispielsweise eine schöne ISO-Formatierung bzw. Konvertierung (also „rein“ und „raus“) zu ermöglichen, dem sei folgende Lösung ans Herz gelegt. Jegliche eigenen Date-Serialisierer aus früheren Versionen sind nicht mehr notwendig.

Lösung bei stackoverflow