Cogito Ergo Blog

Spring ELResolver für Unified Expression Language und JSF 1.2

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.

Weiterlesen →

[:de]

Spring als Factory für JSF-Components

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>

eine ApplicationFactory eingetragen, die Spring ins Spiel bringt, um JSF-Components zu erzeugen. Im letzten Artikel hatte ich das benutzt, um Komponenten wie SpringBeans zu erzeugen und zu konfigurieren.

Wenn Spring die Komponenten erzeugt, dann lassen sich alle Spring Features voll zum Einsatz bringen, unter anderem auch AOP:

Man kann z.B. abhängig von der ROLE eines User eine Komponente anzeigen oder nicht. Hierzu schreibt man einen MethodInterceptor, der die Aufrufe der “encode*”-Calls auf die Komponente überprüft. Die SpringApplication kann aber noch mehr. AOP läßt sich nämlich auch auf die Standard-Komponenten anwenden …

Weiterlesen →

JSF Spring Integration

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.

Weiterlesen →

Acegi Security-Framework für Spring

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.

Weiterlesen →

Ärgernis beim Testen

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.

EasyMock Classextensions

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 …

Weiterlesen →

Swing-FileChooser

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.

JNative

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”.

Weiterlesen →

Einfacher …

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.

Weiterlesen →

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.

Context cachen

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.

Weiterlesen →

[:de]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 …

Weiterlesen →

Gestern abend bin ich zufällig über eins der Sub-Projekte von Spring gestolpert: Spring-WS (Spring WebServices). Beim Lesen der Dokumentation stach mir die Behauptung ins Auge "Best Practice made easier", gemeint ist ein Contract-First Ansatz und das Arbeiten direkt mit den XML-Nachrichten.

In einem eigenen Abschnitt wird ausgeführt, warum (speziell im Falle von WebServices) der Contract-First Ansatz der Bessere ist:

Zum einen lassen die Type-Definitionen mit XML Schema Konstruktionen zu, die in Java (um diese Sprache geht es hier ;-)) gar nicht möglich sind.

Zum anderen lassen bestimmte Sprachkonstrukte, wie zyklische Bezüge nicht einfach so nach XML abbilden.

Deshalb, so die Schlussfolgerung, sei es das Beste, direkt mit den XML-Nachrichten zu arbeiten. Hierfür gibt’s ja schließlich eine Reihe von APIs mit denen sich das einfach bewerkstelligen läßt.

Als krönender Abschluss wird, im Falle einer neuen Version des Contracts und damit anderer XML-Nachrichten, auf die Möglichkeit verwiesen, diese unter Umständen ganz einfach mit XSLT wieder auf die "Old-Style"-Nachricht abzubilden, und somit müßte man nicht mal eine neue Java-Implementierung schreiben.

Geht’s noch …

In der Tat, um mal beim letzten Punkt anzufangen, man braucht keine neue Java-Implementierung und auch kein neues Java-Interface, aber dafür ein XSLT-Stylesheet. Und wenn das dann nicht so arbeitet, wie man gedacht hat, dann baucht man einen Debugger für die Transformation-Engine, damit man sieht wo es schief geht ….

Weiterlesen →