Cogito Ergo Blog

Hatte endlich mal Gelegenheit mich mit einer NoSQL Datenbank zu beschäftigen: Cassandra von Apache. Allerdings fühlte ich mich aus Anwender – in meinem Fall also Anwendungsprogrammierer – in die Steinzeit der Datenbankprogrammierung zurückversetzt: es gibt nur proprietäre Schnittstellen und die sind auch nicht abgekündigt (Thrift). Selbst Apache empfiehlt auf ein abstrakteres API wie zum Bespiel Hector zu setzen.

Leider fühlt sich auch Hector in keiner Weise so an wie man es von konventioneller Datenbank-Programmierung gewohnt ist. Das Java-API ist nach meinem Geschmack “gewöhnungsbedürftig” um es einmal diplomatisch auszudrücken.

Dabei gibt mit Spring-JDBC (oder neuerdings mit Spring-Data) längst gute Beispiele wie man es gut machen kann. Jetzt kann man natürlich einwenden, dass diese “alten” Ansätze für SQL-Datenbanken gemacht sind und sich daher nicht für NoSQL Lösungen eignen, aber wenn man zweimal hinsieht, dann merkt man schnell, dass das gar nicht stimmt.

Weiterlesen →

Seit langem bin ich mal wieder aktiv in der Implementierung einer Komponente, wenn auch erst mal nur ein Prototyp.

Die Persistenz ist – nach dem neusten Trend “back to the roots” – nur noch mit dem JdbcTemplate von Spring gemacht. Da kann man wieder richtiges SQL schreiben und weiß auch genau was passiert (bei Hibernate war ich mir nicht immer so ganz sicher).

Als es dann ans Testen ging und ich mir Gedanken um die Testabdeckung machte, fiel mir auf, dass das was bei if-Anweisungen oder bedingter Zuweisung im Java-Code als “missed 2 of 4 branches” an gemeckert wurde, an vielen Stellen in den Where-Clauses der SQL-Statements genauso auftritt.

Die Coverage in Java war also bei mancher Methode auf 100% aber das SQL-Statement ließ viele Varianten von ResultSets zu je nach dem, was man für Testdaten verwendet und welche konkreten Parameter man bindet.

Wie also läßt sich die SQL-Coverage messen?
Weiterlesen →

Schon in einigen Projekten war die Herausforderung bestimmte Abläufe oder auch „Prozesse“ hochskalierbar, verlässlich ausführen zu können. Dabei kam dann von den einen Projektverantwortlichen schnell der Ruf nach einer Workflow-Engine, von den anderen eher das Gegenteil: „Bloß keine Workflow-Engine …“.

Ich selbst bin auch nicht unbedingt ein Freund von „graphischer Programmierung“ oder geschwätzigem XML, was fast schon Programmiersprache sein will, aber in fast jeder
Hinsicht unhandlicher ist als eine „normale“ Programmiersprache wie Scala oder Java.

Aus diesem Grund reizte mich die Idee einen alternativen Ansatz zu versuchen. Da ich, wie gerade schon erwähnt, kein Freund von „in XML programmieren“ bin, sollte die
Beschreibung des „Prozesses“ – das Prozessmodell – in Java erfolgen.

Hier bietet sich das State-Pattern an, welches eine Prozessablauf mit Hilfe von Zustandsobjekten und einem Kontext beschreibt. Konkret werden also nur Interfaces bzw. abstrakte Basisklassen benötigt, die von einem konkreten Prozess implementiert
werden. Dazu der „Contract“ der den Ablauf / die Semantik beschreibt und schon kann ein „Prozess“ statt in XML in Java geschrieben werden.

Weiterlesen →

Der Mondrian OLAP Server, der seit einer Weile zur Pentaho-Suite gehört, kann mit einer recht leistungsfähigen Implementierung von Data-Cubes und der MDX-Abfragesprache aufwarten.

Allerdings kommt die mitgelieferte Oberfläche etwas altbacken daher. JPivot und auch das Charting machen für meine Begriffe nicht viel her. Auch die eingesetzte Web-Technologie ist eher von gestern: JSPs und Taglibs oder ein selten genutztes Web Framework WCF.

Da wurde bei mir schnell der Wunsch wach, Mondrian in JBoss SEAM zu integrieren und die Chart evtl. mit Open Flash Chart etwas aufzupeppen.

Der folgende Artikel zeigt den ersten Versuch, ein Anfang ist also gemacht.

Weiterlesen →

Will man mit GRAILS ein Real-World-System beschreiben und dabei das schnelle Erstellen von CRUD-Applikationen nutzen, steht man schnell vor dem Problem dass
damit Many-To-Many Verknüpfungen nicht gehen.

Es wird zwar angeboten, wie bei One-To-Many, aber wenn „Add …“ gewählt wird, kann zwar ein neues Child angelegt werden, aber die Verbindung wird nicht
hergestellt.

Auch beim One-To-Many gibt es auf der Many-Side Einschränkungen: es kann nur ein Child per „Add …“ hinzugefügt werden. Weder wird das Zuordnen eines bereits
angelegten Childs ermöglicht, noch wird das Löschen angeboten.

Ausserdem ist die Doku nicht konsistent: Beim Domain-Mapping mit GORM heißt es:

„Grails supports many-to-many relationships by defining a hasMany on both
sides of the relationship and having a belongsTo on the side that owns the relationship“.

Richtig ist aber das belongsTo gehört auf die Child-Side, nicht auf die Parent-Side, so wie es auch im zugehörigen Beispiel ist.

Wichtig ist hier nämlich:

„The owning side of the relationship, in this case Author, takes
responsibility for persisting the relationship and is the only side
that can cascade saves across.“

Also nur die Parent-Side hat den Cascading-Save und somit sollte nur von dort aus geändert werden. Jedenfalls werden nur die von der Parent-Side ausgemachten
Änderungen ohne weiteres persistiert. Würde man von der Client-Side aus ändern, dann müßte die zugehörige Änderung im Parent explizit gesetzt und persistiert werden.

Um die Unterstützung für Many-To-Many in den mit Scaffolding generierten Views zu bekommen, sind die Templates anzupassen. Wie das geht beschreibt der folgende
Artikel.

Weiterlesen →

Zwar gibt es mit den Spring-Modules bereits Support für die Verwendung von Spring zusammen mit jBPM, aber die Verwendung von Spring-Beans als Actions mit Hilfe des Delegate von Spring-Modules ist etwas umständlich:

<action name="myAction" config-type="bean" 
            class="org.springmodules.workflow.jbpm31.JbpmHandlerProxy">
    <targetBean>jbpmAction</targetBean>
    <factoryKey>jbpmConfiguration</factoryKey>
</action>

Es muss also jedesmal der ProxyHandler hingeschrieben werden und die Target-Bean konfiguriert werden, das sieht doch sehr unschön aus. Meine Vorstellung war eher eine Action-Definition wie diese:

     <spring-action bean="myAction" />

Wie sich zeigt ist jBPM so flexibel, dass diese Vereinfachung mit etwas Konfiguration und einer Hilfsklasse leicht erreicht werden kann.

Weiterlesen →

SpringELResolverSupport konfiguriert ELResolver mit Spring

Die Überschrift sagt eigentlich schon alles: der ELResolver wird selbst durch Spring erzeugt und konfiguriert.

Manchmal ist es nützlich oder sogar notwendig, dass ein ELResolver durch Spring konfiguriert wird. Wenn man den Resolver allerdings direkt in die faces-config.xml einträgt, dann geht das nicht.

Stattdessen wird ein Helper eingetragen, der auf die eigentlichen ELResolver delegiert…

Weiterlesen →