Blog

Alle Beiträge in der Kategorie 'Software-Architektur'

Ein Blocker in Hibernate

Die JPA (Java Persistence API) ist seit geraumer Zeit eine der innovativsten Neuerungen in der Enterprise-Java-Welt. Geprägt durch verschiedene Technologien sind viele elegante Lösungen für wiederkehrende Problemstellungen in eine Spezifikation eingeflossen. Hibernate ist eine sehr verbreitete Open-Source-Lösung, die die JSR-220 und JSR-317 implementiert. Eine essentielle Verbesserung von JPA gegenüber J2EE Entity Beans ist die Unterstützung von Vererbung. Zum Bedauern vieler Entwickler existiert jedoch in Bezug auf Vererbung ein schwerwiegender Bug in Hibernate, welcher zwar bereits bekannt ist, aber leider nicht korrigiert wurde, obwohl die Lösung dafür bereits existiert.

weiterlesen

Unit-Tests im Spring Context mit JUnit und Mockito

Im täglichen Projektgeschäft kommt es noch immer vor, dass Entwickler und auch Projektleiter vom Nutzen von Tests überzeugt werden müssen. Um in einem Umfeld, in dem bis auf Tests durch die Qualitätssicherung noch keine oder nur Alibi-Tests vorliegen, ist es ratsam, nicht gleich den Big Bang zu starten und TDD (Test Driven Development) einführen zu wollen. Ratsam ist eine Orientierung an der klassischen Testpyramide, bei welcher Unit-Tests die Voraussetzung für weitere Tests darstellen.

Sind die Entwickler und Projektleiter einmal ins Boot geholt, muss eine zweite Hürde überwunden werden. Es muss den Entwicklern eine konfigurierte Umgebung zur Verfügung gestellt werden, in welcher diese ihre Tests ohne großen Aufwand schreiben und ausführen können. Welche Umgebung vonnöten ist, um im Spring 2.5 Context mit JUnit 4.4 und dem Mock-Framwork Mockito in Version 1.8.5 testen zu können, soll dieser Blogbeitrag klären.

weiterlesen

Fehlerhafte Fehlerbehandlung – aka Exception Handling Smells

Fehler treten ständig und überall auf – wer sich regelmäßig mit Softwareentwicklung beschäftigt, dem ist diese (unangenehme) Tatsache sehr bald nur allzu bewusst. Seltsamerweise schlägt sich dieses Bewusstsein oft nicht im geschriebenen Code nieder. Das kann viele Gründe haben: Zeitdruck, mangelnde Sorgfalt oder schlichtweg fehlende Aufmerksamkeit für das Problem.

Die Folge: Falls Funktionalität implementiert werden soll, die auf Komponenten mit nachlässiger Fehlerbehandlung zurückgreifen muss, so ist die Möglichkeit zu einer korrekten Fehlerbehandlung bereits verbaut. Das verleitet dazu, dieses Thema auch bei der Weiterentwicklung zu vernachlässigen. So können Systeme entstehen, die sich aus Sicht der Anwender und Entwickler völlig unberechenbar verhalten, falls auch nur eine Kleinigkeit schief geht – und wie jeder in der Softwareentwicklung weiß, ist das nun mal leider der Regelfall. Dabei kann man diese Probleme recht einfach vermeiden, wie ich an einigen einfachen Beispielen zeigen möchte.
weiterlesen

Apache Ivy: eine sinnvolle Ergänzung zu Apache Ant

Wenn es um Flexibilität im Build-Management geht, distanziert man sich gern von Maven 2. Zwar kann man es durch diverse Einstellungen „umbiegen“, aber das ist nur teilweise zielführend. Möchte man wahrhaft flexibel sein und auch bleiben, so fällt die Entscheidung meist auf Gradle oder Ant. Gradle hat den Vorteil, dass man praktisch Java-Code schreiben kann, Ant zeichnet aus, dass es, so wie Maven 2, rein XML-basiert ist und dennoch als Script-Sprache klassifiziert wird. Apache Ivy erweitert die Funktionalität von Ant um alle notwendigen Features, die zum Auflösen von Abhängigkeiten nötig sind und ermöglicht die Publizierung von Artefakten in ein beliebiges Repository.
weiterlesen

"Türsteher für Bohnen" im Java Magazin

Türsteher für Bohnen – Bean Validation mit domänenspezifischen Typen in der Praxis
Simon Zambrovski und Oliver Ochs, Java Magazin Ausgabe 4.2011

Cover des JavaMagazin 4.2011

Nachdem vor Kurzem Simon Zambrovski und Oliver Ochs bereits einen IT-Talk zum Thema Bean Validation gehalten haben, ist nun auch ein JavaMagazin-Artikel zum gleichen Thema erschienen.

In einer Java-Enterprise-Anwendung werden Daten erfasst und verarbeitet. Diese Daten müssen validiert werden. Die Validierungslogik ist meist eng an die Daten, die validiert werden, gekoppelt. Darum werden durch JSR-303 Bean Validation die Validierungsregeln direkt an die Daten annotiert. Der JSR-303 ist ein Teil der Java EE 6. Das heißt, man kann Bean Validation in Java EE 6 sowohl mit JSF als auch mit JPA einsetzen. Doch auch außerhalb der Java EE 6-Welt lässt sich Bean Validation z.B. mit Spring 3 verwenden.

Der Artikel bietet einem praxisnahen Überblick über den Einsatz von JSR-303 mit all diesen Frameworks. Zudem wird die Verwendung von domänenspezifischen Typen tiefer gehend erläutert.

Man findet den Artikel in der Rubrik „Enterprise“.