Blog

In der letzten Zeit findet man diverse Veröffentlichungen oder auch Vorträge auf Usergroups und Konferenzen, die scheinbar das eine Ziel haben, Enterprise JavaBeans aus der Anwendungsarchitektur zu verbannen. Da werden zunächst EJBs durch entsprechende CDI-Beans ersetzt, weil die ja leichtgewichtiger seien. Aus Entwicklersicht kann ich dem nicht zustimmen: Aus einer einfachen Klasse wird durch eine einzelne Annotation eine EJB. Wenn das schwergewichtig ist ... Natürlich ist auch der Laufzeitaspekt zu berücksichtigen. Und da sind EJBs tatsächlich etwas langsamer als CDI-Beans, aber der Unterschied ist relativ gering - vgl. dazu auch Adam Biens Weblog. Nach der Ersetzung der EJBs stelt man dann fest, dass einige Aspekte fehlen, die EJBs mitbringen, CDI-Beans aber nicht. So z. B. die deklarative Transaktionssteuerung. Die Verfechter des EJB-Abschusses programmieren sich dann mal eben (*) einen CDI-Interceptor mit dem Binding über eine Annotation namens @Transactional o. ä. Analog könnte man für Security, asynchrone Methoden, Timer etc. vorgehen. Ich frage mich nur "warum?". Warum um alles in der Welt sollte ich eine vorhandene, funktionierende Lösung durch eine selbstprogrammierte ersetzen? Als Argument wird gelegentlich angeführt, dass eine Lösung ohne EJBs bspw. in einem Tomcat mit CDI-Container (Weld oder OpenWebbeans) lauffähig wäre. Ja, schon - aber die Lösung mit EJBs ist eben auch in einem Tomcat lauffähig, wenn ich einen entsprechenden Container hinzunehme. Es gibt doch genau diese Plattformen - SIwpas, TomEE, Resin etc., die das nötige Java-EE-6-Webprofil implementieren. Warum sollte ich mich denn selbst kasteien und nur ein Subset davon nutzen? Es muss wohl doch daran liegen, dass EJBs böse sind ... (*) "mal eben" ist in der IT ein Signalwort. Es bedeutet, dass hier höchste Aufmerksamkeit hinsichtlich des zu veranschlagenden Aufwands geboten ist. PS.: Eine Vereinheitlichung der in grossen Teilen konkurrierenden Komponentenkonzepte EJB und CDI ist sicher sinnvoll. Das sollte aber IMHO im Standard (Java EE 7) passieren und nicht mit "Mach ich mal eben selbst"-Schnellschüssen.

Die häufig gestellte Frage, ob Java EE oder Spring eingesetzt werden soll, muss man m. E. auf den vergleichbaren Bereich beider Welten eingrenzen: Es geht hier um die Plattform von Enterprise-Anwendungen, d. h. im Kern um den Dependency Injection Container. Hier hatte J2EE ganz deutliche Schwächen, die in meiner Vorstellung das Spring Framework erst richtig interessant und vorteilhaft gemacht haben. Java EE 6 hat hier aber ganz erheblich nachgelegt und bietet mit CDI einen extrem einfachen und leistungsfähigen Mechanismus zur kontextbasierten Komposition von Anwendungsbausteinen an – und das in nahezu allen Fällen ohne explizite Konfiguration. Die „Schmerzen“, die seinerzeit den Einsatz von Spring nahegelegt haben, sind also nicht mehr vorhanden.

Für den Einsatz von Java EE 6 spricht, dass es abgestimmte und verbindliche Spezifikationen gibt, die eine Stabilität der Anwendungen auch über Versionswechsel hinweg ermöglichen. Im proprietären (= nicht-standardisierten) Bereich ist das nicht so leicht zu garantieren, wie uns bspw. die Historie von Struts vor Augen führt. Sehr positiv finde ich weiterhin die Existenz mehrerer unabhängiger Java-EE-Implementierungen (auch wenn wir für das Full Profile noch ein wenig Geduld aufbringen müssen), wodurch ein Vendor Lock-In im Ansatz abgewehrt wird. In dem Zusammenhang ist uns die (zwar schnell entschärfte) Ankündigung von SpringSource im Herbst 2008, Maintenance Releases kostenpflichtig zu machen, noch gut in Erinnerung.

Die gemachten Überlegungen gelten natürlich nur für Projekte, die noch vor der Auswahl der Plattform stehen - es lohnt nicht, bestehende Software umzubauen. Wenn man mir aber für neue Projekte die Eingangsfrage stellt, entscheide ich mich für die einfache Variante: Java EE 6.

Das übliche Verfahren, lokalisierte Meldungen zu erzeugen, ist die - meist implizite - Nutzung von PropertyResourceBundle. So bezieht bspw. Bean Validation seine Meldungen aus einem Resource Bundle mit Namen ValidationMessages. Dieses materialisiert sich üblicherweise aus Classpath-Ressourcen namens ValidationMessages.properties, ValidationMessages_de.properties etc.

Problematisch ist bei diesem Verfahren, dass z. B. nur eine Datei namens ValidationMessages.properties verwendet wird, auch wenn es davon mehrere im Classpath gibt. Damit ist leider der Weg verbaut, in einer Utility-Bibliothek bspw. Bean Validation Constraints inkl. der zugehörigen Meldungen auf einfache Weise zu definieren:

- Anwendung definiert Validierungsmeldungen als Classpath-Ressource-Bundle "ValidationMessages" (1),
- von der Anwendung genutzte Bibliothek enthält ebenfalls ein Classpath-Ressource-Bundle "ValidationMessages" (2).
- Validierungsfehler nutzen die Meldungen aus (1), aber nicht (2)!

Abhilfe ist hier leicht zu schaffen: Statt der impliziten Nutzung eines PropertyResourceBundle lässt sich eine Lokalisierung von Texten auch durch explizite Bereitstellung eines Resource-Bundles in Form passend benannter Klassen erreichen, d. h. im Beispielszenario können die Klassen ValidationMessages, ValidationMessages_de etc. zur Verfügung gestellt werden (alle im Default-Paket). Die Klassen müssen von java.util.ResourceBundle abgeleitet sein. In ihrem Konstruktor suchen sie nach allen passenden Classpath-Ressourcen und bauen damit einen interne Lookup-Tabelle auf. Sinnigerweise implementiert man dieses Verhalten in einer entsprechenden Basisklasse:

public class ValidationMessages extends MultiPropertiesResourceBundle
{
}

public class ValidationMessages_de extends MultiPropertiesResourceBundle
{
}

...

public class MultiPropertiesResourceBundle extends ResourceBundle
{
private Map messageMap = new HashMap();

public MultiPropertiesResourceBundle()
{
loadProperties(this.getClass().getName().replace('.', '/') + ".properties");
}

public MultiPropertiesResourceBundle(String bundleName)
{
loadProperties(bundleName + ".properties");
}

private void loadProperties(String resourceName)
{
try
{
Enumeration found = Thread.currentThread().getContextClassLoader().getResources(resourceName);
while (found.hasMoreElements())
{
URL url = found.nextElement();
loadMessages(url);
}
}
catch (IOException e)
{
// ignore
}
}

private void loadMessages(URL url)
{
Reader reader = null;
try
{
reader = new InputStreamReader(url.openStream(), "UTF-8");

Properties prop = new Properties();
prop.load(reader);

for (Entry entry : prop.entrySet())
{
String key = (String) entry.getKey();
if (!this.messageMap.containsKey(key))
{
String value = (String) entry.getValue();
this.messageMap.put(key, value);
}
}
}
catch (IOException e)
{
// ignore
}
finally
{
try
{
reader.close();
}
catch (Exception e)
{
// ignore
}
}
}

@Override
public Enumeration getKeys()
{
ResourceBundle parent = this.parent;
return new ResourceBundleEnumeration(this.messageMap.keySet(), (parent != null) ? parent.getKeys() : null);
}

@Override
protected Object handleGetObject(String key)
{
return this.messageMap.get(key);
}
}