Hibernate Interceptor mit Play 1.2.x

Update: Man beachte das PS!

Neulich wollte ich (möglichst generisch) wissen, welches Feld von einer Entity modifiziert wurde. Internet sagt, das ginge mit einem Interceptor:

Leider ist für Play nicht offensichtlich, wie man einen solchen einbindet… zumindest nicht für 1.2.x. Es gibt hibernate.ejb.interceptor, das ist es aber nicht. Tatsächlich gibt es “parallel” (“This property can not be combined with hibernate.ejb.interceptor”) noch hibernate.ejb.interceptor.session_scoped – und der geht:

Good to know: Man kann die Entity als solche hier nicht mehr ändern! Man kann aber das zu ändernde Property in currentState suchen und setzen (oder ergänzen) :-) Dann sollte man true zurückgeben, statt super.onFlushDirty(...). Quelle.

<Update>Interceptors haben noch einige andere nette Methoden, so kann man beispielsweise zentral checken, welche Entitäten geändert, inserted oder deleted worden sind.</Update>

PS: Internet sagt außerdem, dass Play schon einen eigenen Interceptor nutzen würde… klang für mich ein wenig so, als würde es Probleme geben, wenn man den “überschreibt” – ich konnte aber keine feststellen und das ist leider auch der Fall: im play.db.jpa.JPAPlugin wird ein eigener Interceptor verwendet, der dafür sorgt, dass Entitäten nicht automatisch gespeichert werden (Hibernate Standard?). Das bloße Verwenden eines eigenen Interceptors hebelt dies aus!

Play Dependencies für JBoss ActiveMQ mit Zookeeper

Es gibt bereits ein gutes Tutorial, wie man eine MQ via Zookeeper anspricht, hier aber noch mal explizit für Play (1 und 2).

Schritt 1: Libraries hinzufügen

Play 1

Die Excludes waren für mein Setup nötig, das müssen sie aber nicht generell sein:

Damit das funktioniert, müssen die folgenden Repositories in den Ivy-Setting definiert werden:

Eine Anmerkung dazu: Das “Early Access” Repo ist meiner Einschätzung nach eigentlich nicht nötig; alle letztlich verwendeten Dependencies kommen aus dem “Releases” Repo. Aber: Offenbar gibt es irgendwelche transitiven Dependencies, die dort zu finden sind. Sie werden “später” durch andere transitive Dependecies “überschrieben”, aber sie müssen trotzdem aufgelöst werden können! Andernfalls funktioniert zwar auch alles, aber es gibt unschöne Warnings. Und ich habe einige Zeit darauf verwendet, das “Early Access” Repo durch force und exclude wegzukonfigurieren – ein Fass ohne Boden :-)

Play 2

Schritt 2: Konfiguration

Schritt 3: Im Code

HTH!

MS SQL: Aktuellen Autoincrement für bestimmte Tabelle

Man liest oft

Das funcktioniert aber nur bsplw. nach einem SELECT. Genereller funktioniert dagegen

von

Java: Object Type Mappings in Elasticsearch

Verschachtelte Strukturen in Elasticsearch zu mappen, ist strukturell gesehen eigentlich gut dokumentiert, siehe Object Type (Achtung: Nicht zu verwechseln mit Nested Type!). In Java kann dabei trotzdem einiges schiefgehen – zumindest in v0.90.x, über die aktuellen Versionen kann ich nichts sagen.

Zuerst ein Klassiker, wenn man sich die zahlreichen Tipps dazu im Internet ansieht:

Merge failed with failures {[mapper [field.innerField] has different index values, mapper [field.innerField] has different tokenize values, mapper [field.innerField] has different index_analyzer]}

Das liegt gerne mal daran, dass der Index vor dem Mapping aufgebaut wurde. Was aber nicht bedeutet, dass man das selber explizit so macht! Es kann ganz simpel daran liegen, dass die früher erzeugten (und jetzt veralteten) Dateien auf der Platte nicht mehr passen. Alle Dateien löschen und neu erzeugen lassen, dann kann der Fehler schon verschwunden sein m(

Dann, auch sehr verwirrend: Der XContentBuilder hat eine string()-Funktion (nicht zu verwechseln mit toString()). Die hilft beim Debuggen insofern, als dass man das erzeugte Mapping/JSON ausgeben kann. Allerdings “tut” string() intern irgendwas, keine Ahnung, den Stream schließen oder so. Mit einem string() im Code bekommt man eine NullPointerException in UTF8JsonGenerator.writeRaw(UTF8JsonGenerator.java:670). Tollerweise (trollerweise?) liegt die Klasse zwar unter org.elasticsearch.common.jackson.core.json.UTF8JsonGenerator, die Sourcen sind aber nicht Teil der ES-Sourcen… und der UTF8JsonGenerator hat sehr viele writeRaw()-Methoden.

Bis man darauf kommt, dass es ausschließlich an string() liegt, kann schon mal einige Zeit vergehen: Mit einem string() im Code kann man zwar das erzeugte JSON ausgeben, dieses ist aber völlig irrelevant. Es kann sogar ungültig sein, etwa durch ein überzähliges endObject() – durch string() sieht man statt des eigentlichen

 JsonGenerationException: Current context not an object but ROOT

nur den NullPointer von oben.

Trotzdem ist string() nötig, denn drölf verschachtelte endObject() und field() werden schnell unübersichtlich. Meine Empfehlung: Das JSON unter Einsatz von string() gemäß der Doku aufbauen, string() dann auskommentieren, und erst dann die auftretenden Fehlermeldungen lesen.

Java: Fields (inkl. Typ, Getter und Setter) dynamisch auslesen

zusammengestoppelt auf stackoverflow

Java: “T implements Interface”

Folgendes geht NICHT:

Aber das hier geht:

That would require an object of type T to both extend B and implement SomeInterface.

Abgefahren. Habe ich bis heute noch nie gesehen, kommt aber gerade ganz praktisch :-)