Beispiel 1: Verwendung im AJAX-Layer

Um auf die Metadaten außerhalb von Java im JavaScript einer AJAX-GUI zugreifen zu können, wird aus den MetaBeans ein JSON-String erzeugt, den ein Servlet zurückgeben kann:

public void service( HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/javascript");
JSONGenerator jsonGenerator = new JSONGenerator();
PrintWriter writer = res.getWriter();
try {
String output = jsonGenerator.toJSON(manager.findAll().values());
writer.write(output);
} catch (Exception e) {
throw new ServletException("error creating JSON for metaBeans", e);
}
}


Dabei werden auch die Typinformationen von Java nach JSON übertragen, da diese ansonsten verloren gingen. Die Beans selbst überträgt das AJAX-Framework DWR, was nicht Gegenstand dieses Eintrages ist.

Beispiel 2: Verwendung im Webservice-Layer

Eine weitere Einsatzmöglichkeit stellt sich bei Validierung eingehender Objekte eines Webservice. Am Beispiel der Webservice Frameworks XFire oder CXF kann eine eigene Invoker-Implementierung konfiguriert werden, welche die eingehenden Beans validiert. Die zu validierenden Methoden und Parameter werden durch die Annotation @Validate gekennzeichnet.

Auszug aus einem Webservice-Interface:
@Validate
void save(@Validate Address address) throws ValidationException;

Entdeckte ConstraintViolations können der Exception mitgegeben werden.

Im Invoker wird das Validierungsframework aufgerufen (Beispiel für XFire):

public Object invoke(Method m, Object[] params, MessageContext context) throws XFireFault {
BeanValidator validator = new BeanValidator();
ValidationResults results = validator.validateCall( m, params);
if (results != null && !results.isEmpty()) {
throw new XFireFault(new ValidationException(results), XFireFault.RECEIVER);
}
return super.invoke( m, params, context);
}


Die zugehörige Konfiguration für XFire sieht dabei so aus:
<beans>
<bean id="TxInvoker" class="com.example.xfire.TransactionalInvoker"
scope="prototype"/>


<service xmlns="http://xfire.codehaus.org/config/1.0">
<name>ExampleService</name>
<serviceClass>com.example.service.ExampleService</serviceClass>
<implementationClass>com.example.service.ExampleServiceImpl</implementationClass>
<serviceFactory>jsr181</serviceFactory>
<invoker>#TxInvoker</invoker>
</service>
</beans>

Weitere Anwendungsmöglichkeiten sind die Visualisierung der Pflichtfelder und Validierungsfehler in Swing-GUIs oder einem Webformular.

Ausblick

Seit Oktober 2008 entsteht eine Referenzimplementierung, die sich an Hibernate-Validator orientiert. Von der veröffentlichten Draft-Spec des JSR-303
wurde dabei in den letzten Monaten mehrfach massiv abgewichen, um neue Features und Anregungen, die von der Java-Community eingegangen sind, einzubeziehen. Das agimatec-validation framework implementiert den jeweils aktuellen Stand der APIs möglichst zeitnah und vollständig. Wir gehen davon aus, dass sich bis zum offiziellen 1.0 Release des Standards noch mehrfach einiges ändern wird, da die Referenzimplementierung noch unvollständig ist.

Constraints in Annotations oder mit XML-Deskriptoren sind Metadaten, die den Domainklassen zusätzliche Semantik verleihen, die für diverse Verwendungszwecke mit der Constraint-Metadata-API ausgewertet werden kann.

Diese Anforderung bestand auch schon vor Zeiten der JSR-303 und hat die agimatec GmbH dazu veranlasst, das Framework „agimatec-validation“ im Frühjahr 2007 zu entwickeln. Das Framework ist seither als Basis zur Erzeugung dynamischer AJAX Oberflächen für Portlets und zur Validierung in Webservices produktiv im Einsatz.

Durch die konzeptionelle Nähe war es bei Erscheinen der JSR-303 möglich, das agimatec-validation Framework so zu erweitern, dass damit rasch die erste und bislang vollständigste Implementierung des Specification-Draft als OpenSource veröffentlicht wurde.

Zusätzliche Anforderungen waren dabei, dass

• eine möglichst automatische Generierung der Metadaten als XML-Dateien erfolgt,
• eine Klasse zur Laufzeit unterschiedliche Metadaten und Validierungsregeln besitzen kann (z.B. für rechteabhängige Validierung),
• die „höheren“ Schichten (hier: die GUI-Schicht) die Metadaten erweitern oder selektiv überschreiben können und
• die Metadaten den AJAX GUIs in Form von JSON (JavaScript Object Notation) zur Verfügung stehen sollen.

Generierung aus Datenbankinformationen

Die häufigsten Metainformationen betreffen Pflichtfelder und Feldlängen. Diese sind im Datenbankschema definiert oder durch Annotationen der Package javax.persistence
@Column(nullable, length, unique) oder
@JoinColumn(...)
an den Entity-Klassen definiert. Um aus dem Datenbankschema oder den Annotationen entsprechendes XML zu generieren bieten sich die als OpenSource verfügbaren agimatec-tools an (oder eine MDA-Lösung).

Das hier gezeigte XML folgt dem agimatec-validation Framework, da die JSR-303 bislang noch keine Aussage über XML-Tags getroffen hat:

<beanInfos>
<bean id=“Address“
impl=“test.jsr303.Address“>
<property name=“line1“
mandatory=“true“
maxLength=“30“/>
<property name=“line2“
maxLength=“30“/>
<property name=“zipCode“
mandatory=“true“
maxLength=“5“/>
...
</bean>
...
</beanInfos>


Features und Validators per XML

Häufige Eigenschaften sind direkt als Attribut deklarierbar, sonstige Informationen werden mit <feature>-Tags abgelegt:


<feature key="readonly">
<value class="boolean">true</value>
</feature>


Eigene Validator-Implementierungen werden über das <validator>-Tag konfiguriert:


<beanInfos>
<validator id="email"
java="my.own.EMailValidation"/>
<bean id=“Customer“>
<property name=“emailAddress“>
<validator refId="email"/>
</property>
</bean>
</beanInfos>


Nicht alle Metadaten sind zur Validierung relevant, sondern können für andere Zwecke z.B. zur Erzeugung einer Oberfläche genutzt werden. So können z.B. Feldreihenfolgen im Eingabeformular, Felder zur Darstellung in einer Tabelle oder die Properties zur Anzeige einer Beschreibung eines Objekts aus den Metadaten hervorgehen. Hier sind der Phantasie der GUI-Entwickler kaum Grenzen gesetzt.

Da die Metadaten aus diversen Quellen (Annotations, unterschiedlichen XML-Dateien und/oder den JDK-BeanInfos) zusammengestellt werden, können Zusatzinformationen beispielsweise in gesonderten XML-Dateien gehalten werden, während andere Informationen per Generierung zustande kommen.

Jede XML-Datei mit Metadaten muss registriert werden:

MetaBeanManager manager = new MetaBeanManager();
manager.addResourceLoader("beanInfos.xml");

Auf die Metadaten einer Domainklasse kann alternativ zur Metadata-API des JSR-303 direkt über den MetaBeanManager zugegriffen werden:

MetaBean metabean = manager.findForClass(Address.class);
// oder
metaBean = manager.findForId(„Address“);


Neben den seit Jahren bekannten proprietären Validierungsframeworks liegt seit März 2008 mit der JSR-303 ein Spezifikationsvorschlag für eine Java API für JavaBeans vor, der zukünftige Tools und Standards beeinflussen wird.

In den folgenden drei Einträgen stelle ich

a) Grundkonzepte der JSR-303
b) eine erste Implementierung des Standards
und
c) Beispiele für Integrationsmöglichkeiten und die Referenzimplementierung
vor.

Datenvalidierung ist eine allgemeine Aufgabe, die leider über die meisten Schichten einer Anwendung verteilt ist und dabei oftmals die Implementierung gleicher oder ähnlicher Regeln in jeder Schicht zur Folge hat. Dies führt zu doppeltem Code und Fehleranfälligkeit.

Für die Konsistenzprüfung umfangreicher Modelle von Businessentitäten müssen Validierungsregeln deklariert oder programmiert werden. Zu diesem Zweck gibt es seit Jahren bereits eine Vielzahl an proprietären Frameworks, einige Beispiele:

• Apache Common-Validator

• Struts-Validation für Webclients und JavaScript

• Hibernate-Validator (mit JBoss Seam Integration)

• WebWork mit XWork Validation Framework

Diese sind jedoch meist darauf ausgelegt, die Validierung in einer bestimmten Schicht der Anwendung abzusichern und sind sich allenfalls konzeptionell ähnlich. Einen Java-Standard für Deklaration und Prüfung von Validierungs-Constraints gab es bislang nicht.
Seit März 2008 liegt mit der „JSR-303: Bean Validation“ ein erster Vorschlag für einen allgemeinen Validierungsstandard im Javaumfeld vor, der zukünftig Einfluß auf Tools, Produkte und darauf aufbauende Standards haben soll. Ziel der Spezifikation ist es, als Erweiterung des Java-Beans Objektmodells in Java EE und SE eine einheitliche API für alle Schichten, sei es die Persistence Schicht, die Web Schicht und andere GUI-Schichten (z.B. Swing), zu bieten.

Grundkonzepte der Spezifikation

Als Metamodell zur Deklaration von Constraints schlägt der Draft der JSR-303 Annotationen für JavaBeans vor. Ferner wird in Aussicht gestellt, dass auch XML-Deployment-Descriptoren unterstützt werden sollen, was zum Zeitpunkt der Erstellung dieses Artikels aber noch nicht spezifiziert wurde. Alle Klassen der Spezifikation selbst werden sich im Package „javax.validation“ befinden.

Annotation der Domainklassen

Um für die Domainklasse „Address“ festzulegen, dass die Felder „line1“ und „zipCode“ Pflichtfelder sind und die Werte eine maximale Anzahl Zeichen nicht überschreiten dürfen, schreibt man:
public class Address {
@NotEmpty @Length(max = 30)
private String line1;
@Length(max = 30)
private String line2;
@NotEmpty @Length(max = 5)
private String zipCode;
...
}

Folgende Sprachkonstrukte dürfen hierzu mit Annotationen versehen werden:

• Instanzvariablen (field validation)
• Getter-Methoden (method validation)
• die Klasse selbst (bean-level constraints)
• Superklassen und
• Interfaces.

Es ist daher auch möglich, die Klasse „Customer“ durch Annotation ihres Interfaces „Person“ mit Constraints zu versehen:

public interface Person {
@NotEmpty
String getFirstName();
String getMiddleName();
@NotEmpty
String getLastName();
}


public class Customer implements Person {
private String firstName;
private String middleName;
private String lastName;
@Password(robustness = 5)
private String password;
...
}


Alle Constraints aus Oberklassen und Interfaces werden stets vererbt. Neben den Annotationen, welche die Implementierung der Spezifikation mitbringen wird, können beliebige eigene genutzt werden.

Eigene Constraints definieren
Zur Implementierung neuer Constraints müssen die entsprechende Annotation und ein ConstraintValidator erstellt werden.
Die Annotation wird im Domainmodell wie bereits dargestellt verwendet. Aufgerufen wird die Implementierung von einem Validator, welcher darüber entscheidet ob der Constraint erfüllt ist oder nicht.

Dazu folgt ein Beispiel für die Annotation „Pattern“:

@Documented
@Target({METHOD, FIELD})
@Retention(RUNTIME)
@ConstraintValidator(
PatternValidator.class)

public @interface Pattern {
String regex();
String message()
default "{beancheck.pattern}";
String[] groups() default {};
}

Die Implementierung „PatternValidator“ soll den Wert der annotierten Property gegen den angegebenen regulären Ausdruck aus „regex“ prüfen. Der ConstraintValidator PatternValidator muss das Interface „javax.validation.Constraint“ implementieren, das die Methode
boolean isValid(Object value, ConstraintContext constraintContext);
beinhaltet.

Mehrfache Zuweisung von Constraints gleichen Typs

Um mehrere gleiche Constraints mit unterschiedlichen Parametern für das gleiche Feld verwenden zu können, unterstützt die Spezifikation sogenannte „multi-valued constraints“. Eine Annotation darf hierbei die eigentlichen Constraint-Annotations als Array im Feld „value“ beinhalten:

@Documented
@Target({ElementType.METHOD, FIELD})
@Retention(RUNTIME)
public @interface Patterns {
Pattern[] value();
}


In der Verwendung liest sich dies dadurch folgendermaßen:

public class Engine {
@Patterns({
@Pattern(regex = "^[A-Z0-9-]+$"),
@Pattern(regex = "^....-....$")
})
protected String serialNumber;
...
}


Das Beispiel zeigt die Constraint-Definitionen zweier @Pattern für das Feld „serialNumber“ in einer Domainklasse namens „Engine“.

Für die eigentliche Validierung sieht die Spezifikation das Interface „Validator“ vor. Es definiert diverse validate*() Methoden für Objekte oder einzelne Properties, welche bei Verstoß gegen die festgelegten Validierungsregeln die Menge der entsprechenden ConstraintViolation Objekte zurückgeben:

Validator validator = ... ;
Set<ConstraintViolation<Address>>
errors = validator.validate(address);


for(ConstraintViolation each : errors) {
printInvalidContraint(
each.getPropertyPath(),
each.getInterpolatedMessage());
}

An welcher Stelle die Validierung in eine Anwendung integriert werden kann oder sollte ist nicht Bestandteil der Spezifikation.

Dieser Eintrag ist sowieso schon zu lang, aber alle Features im Detail zu zeigen, würde den Rahmen endgültig springen, daher hier einige weitere Features der JSR-303 stichpunktartig:

Validierung von Objektgraphen
Durch die Annotation „@Valid“ können auch referenzierte Objekte in die Validierung ihres Parent-Objects einbezogen werden. Auf diese Weise ist es möglich, mit einem Aufruf der Validierungs-API ganze Objektgraphen zu validieren.

Mehrsprachige Meldungen
Ein Constraint kann eine eigene Fehlermeldung im Annotation-Element „message“ festlegen. Die Spezifikation beschreibt die Möglichkeit, die Meldungen mehrsprachig in ein ResourceBundle auszulagern und in den Annotationen nur die sprachunabhängigen Schlüssel zu referenzieren.

Mit Class-Level Constraints können ganze Objekte anstatt einzelner Properties validiert werden. Als Anwendungsbeispiel kann man sich einen Validator vorstellen, der überprüft, ob die angegebene Stadt in einer Adresse zu Land und Postleitzahl passt.

Validierungsgruppen ermöglichen eine teilweise Validierung und werden von der Community noch diskutiert, wobei die Expert Group nach Möglichkeiten sucht, dies verständlich und gleichzeitig flexibel zu gestalten.
Eine Reihenfolge der Validierungen festzulegen ermöglicht die Annotation @GroupSequence.
Mit Hilfe der Gruppen und Reihenfolge ist es möglich, dass in einer Anwendungsschicht nur bestimmte Validierungen durchgeführt werden („Wizzard-Style“) um auch bereits unvollständig initialisierte Objekte prüfen zu können oder die Validierung so gestaltet wird, dass zeitaufwändige Verarbeitungen nachgelagert werden („Short-Circuit“).

Mit der Constraint-Metadata API wird eine Schnittstelle definiert, die Auskunft über die Constraints einer Klasse oder einzelner Properties gibt. Auch diese API steht noch nicht abschließend fest, dürfte aber für Toolhersteller von besonderem Interesse sein.

Wer mehr über die Spezifikation erfahren möchte, sei auf den Blog des Lead-Autors der JSR-303 verwiesen, der für alle Features auch Beispiele vorstellt.

Is it possible to run Lucene on an older Sun Fire T2000?

Yes, but don’t call it run.

Some statistics (using Compass + Lucene)

Index creation (5000 objects): 14502ms

Initial search (“*”): 9544ms

Compare this to a 2.2 Ghz MacBookPro:

Index creation (5000 objects): 1071ms

Initial search (“*”): 614ms

Obviously (ok, it wasn’t for me) the single FPU is the bottle neck.

I have switched to the Mac and was searching for a good tool. Live HTTP Headers is a Firefox Plugin but I don’t really liked it. Installed it today and the interface could be used for three requests, but has no overview for a lot of requests. With a search in the Firefox Add-Ons I found HttpFox. It is exactly the tool I searched for. I nice table with all requests and a split panel of the bottom for request and response headers.

Have a look at the screenshot and install it – as soon as possible. Why?

• Step by step to a faster web app (german)
• Caching with HTTP header (german
• Cache refresh

Datenschützer: Adressen aller Bundesbürger im Umlauf

Ein Skandal! Wie konnte das nur passieren…?

Ich konnte es mir nicht verkneifen.

public class Calculation {
    public static void main(String[] args) {
        Long result = 3l;
        result += new Long(3);

        if(Boolean.parseBoolean("Wrong") || Boolean.parseBoolean("True")) {
            result++;
        }

        System.out.println("Result: " + result );
    }
}

Wer bisher Googles Dienst “Google Browser Sync” nutzte, um seine Browser-Daten wie z.B. die Bookmarks zwischen mehreren Rechnern konsistent zu halten, wurde möglicherweise von der Einstellung des Projekts seitens Google überrascht.

Nun, seit gestern ist die zweite Version (0.2) von Weave, einem Projekt der Mozilla Labs verfügbar:

“Weave is an experimental prototype from Mozilla Labs that integrates online services with Firefox.”

Was auch immer da noch kommen mag, die meisten Funktionen von Googles Tool ersetzt Mozillas Service schon heute. Wer es ausprobieren möchte, kann das AddOn hier herunterladen: services.mozilla.com

Risikobereitschaft ist übrigens in dreifachem Sinne nötig. Erstens befindet das Tool noch im Prototypenstadium, zweitens ist es nicht jedermanns Sache, persönliche Daten über das Internet zu synchronisieren (auch wenn die Daten verschlüsselt auf Mozillas Servern hinterlegt werden) und drittens bemängelt Firefox 3 das Sicherheitszertifikat der Download-Seite… Ich gebe zu, vertrauenserweckend ist das nicht. ;-)