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.
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.
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.
Für die neuen Netbooks ein Notfall-System zu haben ist nicht so einfach wie man zunächst denkt: es fehlt ja das optische Laufwerk.
Damit sind sämtliche Notfall-CDs wie Knoppix oder BartPE, die noch im Schrank liegen, erst mal wertlos. Inzwischen booten aber auch alle Systeme von USB, so auch das neue Akoya mini Netbook. Also schnell das gewünschte BartPE System auf USB übertragen (siehe FAQ bzw. pe2usb.txt im aktuellen BartPE) und los.
Bootet auch, alles bestens, nur leider ist die Harddisk nicht zu finden: Die interne SATA-Platte braucht einen Treiber, damit WinXP darauf zugreifen kann.
Um dieses Problem zu umschiffen, mußte ich eine ganze Weile rumgoogeln, bis klar war wie's geht, deshalb hier kurz die Schritt für Schritt Anleitung.
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.
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...
Seit der Version 1.2 von Java Server Faces sind die alten PropertyResolver und VariableResolver deprecated. Stattdessen sollte man einen ELResolver verwenden. Das hat ausserdem den Vorteil, dass ein ELResolver auch ausserhalb von JSF funktioniert (ab JSP 2.1).
Der vorgestellte ELResolver exponiert den kompletten WebApplicationContext mit allen SpringBeans und kommt darüber hinaus noch mit Support für Springs MessageSources, so dass ein Ausdruck #{bundle.key} direkt auf die MessageSource zu greifen kann.
Wie schon im letzten Beitrag "JSF-Components mit Spring und Velocity-Templates" soll auch bei diesem Beispiel Spring zum Erzeugen von JSF-Componenten benutzt werden.
Noch einmal kurz das Vorgehen: in der faces-config.xml wird mit:
<factory>
<application-factory>
org.springframework.web.jsf.SpringApplicationFactory
</application-factory>
</factory>
Die Integration von JSF und Spring ist mit Spring 2.0 und den neuen Beanscopes schon recht einfach geworden. Was aber immer noch nicht so ohne weiteres geht, ist das Erzeugen von Componenten mit Spring.
Angeregt von Rick Hightower's Sleepless Night in Tucson bzw. seinen Veröffentlichungen auf ArcMind habe ich etwas Code zusammengestellt, der Componenten mit Hilfe von Spring instanziiert und zum Rendern einfach eine Template-Engine wie Velocity oder Freemarker benutzt.
Mit Spring lassen sich diese Komponenten dann einfach konfigurieren und für sehr einfache Sachen ist man mit dem Schreiben der Templates schon fertig.
Wenn man mit Spring statt mit EJB arbeitet, ist ein Aspekt, welcher normalerweise komplett vom ApplikationServer abgedeckt wird, die Sicherheit. Hierzu gibt es die Standard-Lösung, die auch in vielen Artikeln und Büchern erwähnt und besprochen ist: Acegi
Zusammen mit Spring, lassen sich per AOP Interceptoren beim Zugriff auf Businessmethoden von SpringBeans dazwischen "weben", die die Authentisierung des Aufrufers überwachen. Acegi benutzt hierzu einen SecurityContext, der auf unterschiedlichste Weise entstehen und befüllt werden kann.
In meinem konkreten Anwendungsfall wurde die Authentisierung einer WebApplikation mittels HTTP-Basic-Authentication realisiert und in der ersten zunächst scheinbar korrekten Konfiguration zeigten sich seltsame Effekte:
Neben den Zugriffen, die richtig authentisiert waren und demnach ohne weiteres ausgeführt wurden, konnte es passieren, dass manchmal auch ein nicht authentisierter Aufruf durchkam?
Wie sich heraus stellte, lebt der SecurityContext in einem ThreadLocal was im ApplikationenServer (hier Tomcat) mit dem jeweiligen WorkerThread assoziiert ist. Nun konnte es passieren, dass die SecurityContext eines vergangenen Requests "überlebt" hat und bei einem erneuten Zugriff wiederbenutzt wurde. So waren Zugriffe die zufällig mit dem "richtigen" WorkerThread ausgeführt wurden, falsch authentisiert.
Was hier fehlt (und in Acegi ist das nicht vorhanden) ist ein LifeCycle des SecurityContexts der sich am Request orientiert. Was Acegi bietet ist die Kontrolle des LifeCycles über eine Instance von "SecurityContextHolderStrategy" und eine solche "Strategy" für HTTP-Requests will ich hier einmal vorstellen.
Beim Testen mit Unittests verwendet man meist Mock-Objecte, die die "Umgebung" der Klasse, die zu Testen ist "simulieren". Dumm nur, dass diese Umgebung manchmal aus Klassen besteht, die kein Interface implementieren. Wenn dann auch noch einer dieser Klassen "final" ist (oder eine Methode), dann ist man selbst mit so schönen Mock "Generatoren" wie EasyMock am Ende.
Zwar kann EasyMock mit den ClassExtensions auch Mock-Objecte von Klassen erzeugen, aber dazu dürfen diese nicht "final" sein. Das hat damit zu tun, dass unter der Haube mit Hilfe der CGLIB eine Ableitung der betreffenden Klasse erzeugt wird, die als Mock-Object dient. Das aber kann nur funktionieren, wann Ableiten erlaubt ist. Hier kann GLUONJ Abhilfe schaffen ...
Der Swing-FileChooser hat selbst in der Version 6 von Java immer noch nicht das Niveau des nativen FileChoosers erreicht. So steht bespielsweise die wichtige Miniaturansicht für Bilder bei Swing nicht zur Verfügung. Auch das Auswahl "Lasso" bei mehrfach Auswahl fehlt bei der Java-Variante.
Mit JNative gibt es eine einfache Möglichkeit native Code in Java einzubinden, ohne dafür gleich JNI oder den C/C++ Compiler bemühen zu müssen. Der native Code in der DLL (oder dem SO-Modul) ist generisch und ein Call an eine Betriebsystemfunktion wie "GetOpenFile" wird sozusagen in Java "zusammengebaut".
Anläßlich einer Anfrage zum meinem Artikel habe ich das damals doch recht komplizierte Zusammenspiel von ANT, Python und Java einmal refakturiert und in eine einfache Java-Anwendung gegossen.
Herausgekommen ist eine kleine Kommandozeilen Applikation, die aus einer OpenOffice-Datei (altes SXW-Format, kein ODT) eine Docbook XML-File erzeugt, alle Bilder extrahiert und die Links anpasst. Weiterhin wird auf Wunsch auch gleich das 1-Seiten-Html und das mehrseitige HTML erzeugt. PDF und weitere lassen sich leicht ergänzen.
Beim Testen mit HttpUnit und Spring müssen die Servlets und Filter, die über Spring konfiguriert werden mit ihrem Context versorgt werden. Nimmt man hierzu den "normalen" Context-Listener von Spring, hat das den Nachteil, dass bei jedem Start des HttpUnit-ServletContainers der Context neugeladen wird, was unter Umständen viel Zeit in Anspruch nimmt.
Das Zwischenspeichern des Context ist erforderlich und ähnlich wie Spring selbst Basisklassen mit dieser Eigenschaft anbietet, kann auch ein ContextListener geschrieben werden, der den Context speichert und für viele Testruns zu Verfügung stellt.
Manchmal braucht man neben den MVC Mechanismen von Spring-Web auch ein ganz normales Servlet, welches nicht einem Handler entspricht, der ModelAndView zurückgibt. Leider ist so ein Servlet dann aber selbst keine Spring-Bean, sondern muss sich selbst des Spring-Contexts bedienen, um an die Spring-Beans heranzukommen und Dependencies zu setzen.
Ein generisches Spring-Servlet, welches auf eine Servlet-Spring-Bean delegiert, schafft Abhilfe ...