Bean Validation

Die Bean Validation API wird mit der Plattform Java™ Enterprise Edition 6 als Standardmechanismus für die Validierung von JavaBeans auf allen Ebenen einer Anwendung, einschließlich Darstellung, Geschäfts- und Datenzugriff, eingeführt.

Vor der Spezifikation "Bean Validation" wurden JavaBeans auf jeder Ebene einzelnen validiert. Um die erneute Implementierung von Validierungen auf jeder Ebene zu verhindern, haben Entwickler Validierungen direkt in ihre Klassen eingebunden oder Validierungscode kopiert. Dieses Verfahren war häufig sehr unübersichtlich. Eine einheitliche Implementierung für alle Ebenen der Anwendung vereinfacht die Arbeit der Entwickler und spart Zeit.

Die Spezifikation Bean Validation definiert ein Metadatenmodell und eine API, die für die Validierung der Datenintegrität von JavaBeans verwendet werden. Die Metadatenquelle sind die definierten Integritätsbedingungsannotationen, die durch XML-Validierungsdeskriptoren überschrieben und erweitert werden können. Der API-Satz ist ein benutzerfreundliches Programmiermodell, das die Verwendung derselben Integritätsbedingungen für die Validierung auf allen Ebenen der Anwendung ermöglicht. Integritätsbedingungen für die Validierung werden verwendet, um den Wert annotierter Felder, Methoden und Typen zu prüfen, um sicherzustellen, dass diese den definierten Integritätsbedingungen entsprechen.

Integritätsbedingungen können integriert oder benutzerdefiniert sein. Es sind mehrere integrierte Annotationen im Paket "javax.validation.constraints" verfügbar. Sie werden verwendet, um reguläre Integritätsbedingungsdefinitionen zu definieren und um Integritätsbedingungen zu erstellen. Eine Liste der Integritätsbedingungen finden Sie im Artikel "Integrierte Integritätsbedingungen für Bean Validation". Weitere Einzelheiten zum Metadatenmodell und zu den APIs von Bean Validation finden Sie im Spezifikationsdokument "JSR 349 Bean Validation".

Das folgende Beispiel ist eine einfache EJB-Klasse (Enterprise JavaBeans), die mit Annotationen für integrierte Integritätsbedingungen dekoriert sind.

public class Home  {
   @Size(Max=20)
    String builder; 
    @NotNull @Size(Max=20)
    String address;

    public String getAddress() {
         return address;
    }

    public String getBuilder() {
         return address;
    }
    public String setAddress(String newAddress) {
         return address = newAddress;
    }

    public String setBuilder(String newBuilder) {
         return builder = newBuilder; 
    }
}

Die Annotationen "@Size" in "builder" und "address" geben an, dass der zugeordnete Zeichenfolgewert nicht länger als 20 Zeichen sein darf. Die Annotation "@NotNull" in "address" gibt an, dass der Wert nicht null sein darf. Wenn das Home-Objekt validiert wird, werden die Werte für "builder" und "address" an die für die Annotation "@Size" definierte Validatorklasse übergeben. Der Wert von "address" wird auch an die Validatorklasse "@NotNull" übergeben. Die Validatorklassen überprüfen die Werte auf die Einhaltung der gültigen Integritätsbedingungen, und sollte die Validierung einer Integritätsbedingung scheitern, wird ein Objekt "ConstraintViolation" erstellt und in einer Gruppe an den Caller (Aufrufenden) zurückgegeben, der das Home-Objekt validiert.

Bean-Validation-APIs

Das Paket "javax.validation" enthält die Bean-Validation-APIs, die beschreiben, wie JavaBeans über das Programm validiert werden.

ConstraintViolation ist die Klasse, die einen einzigen Integritätsbedingungsfehler beschreibt. Für eine Objektvalidierung wird eine Gruppe von ConstraintViolation-Klassen zurückgegeben. Bei Nichteinhaltung einer Integritätsbedingung wird außerdem eine vom Benutzer lesbare Nachricht ausgegeben, in der die Nichteinhaltung beschrieben wird.

Es wird eine Ausnahme des Typs "ValidationException" ausgelöst, wenn während der Validierung Fehler auftreten.

Die Schnittstelle "Validator" ist die Haupt-API für die Validierung, und eine Validator-Instanz ist das Objekt, das in der Lage ist, die Werte der Java-Objektfelder, -methoden und -typen zu validieren. Die Bootstrapping-API ist der Mechanismus, über den auf eine ValidatorFactory zugegriffen wird, die zum Erstellen einer Validator-Instanz verwendet wird. Für die im Produkt implementierten Anwendungen wird das Bootstrapping automatisch durchgeführt. Es gibt zweit Methoden, mit denen Anwendungen den Validator oder die ValidatorFactory abrufen können. Eine Methode ist Injektion, z. B. mithilfe der Annotation "@Resource", und die andere Methode ist JNDI (Suche in java:).

Im folgenden Beispiel wird Injektion für den Abruf einer ValidatorFactory und eines Validators verwendet:
@Resource ValidatorFactory _validatorFactory;
@Resource Validator _validator;    
Achtung: Wenn die Annotation "@Resource" zum Abrufen eines Validators oder einer ValidatorFactory verwendet wird, dürfen die Elemente "authenticationType" und "shareable" nicht angegeben werden.
Im folgenden Beispiel wird JNDI zum Abrufen einer ValidatorFactory und eines Validators verwendet:
ValidatorFactory validatorFactory = (ValidatorFactory)context.lookup("java:comp/ValidatorFactory");
Validator validator = (Validator)context.lookup("java:comp/Validator");

APIs für die Anforderung von Integritätsbedingungsmetadaten

Die Metadaten-APIs unterstützen Toolprovider, die Integration mit anderen Frameworks, Bibliotheken und Java-EE-Technologien (Java Platform, Enterprise Edition). Der Zugriff auf das Metadatenrepository mit Objektintegritätsbedingungen erfolgt über die Validator-Instanz einer bestimmten Klasse.

XML-Implementierungsdeskriptoren

Neben der Deklaration von Integritätsbedingungen in Annotationen wird auch die Verwendung von XML für die Deklaration von Integritätsbedingungen unterstützt.

Die XML-Validierungsbeschreibung setzt sich aus zwei Arten von XML-Dateien zusammen. Die Datei "META-INF/validation.xml" beschreibt die Bean-Validation-Konfiguration für das Modul. Der andere XML-Dateityp beschreibt Integritätsbedingungsdeklarationen und ist der Methode fr Annotationsdeklarationen sehr ähnlich. Standardmäßig werden alle Integritätsbedingungsdeklarationen, die mithilfe von Annotationen ausgedrückt werden, für die in XML beschriebenen Klassen ignoriert. Es ist möglich, für die Validierung sowohl die Annotationen als auch die XML-Integritätsbedingungsdeklarationen zu erzwingen, indem die Einstellung "ignore-annotation="false"" in der Bean verwendet wird. Das Produkt stellt sicher, dass die implementierten Anwendungsmodule, die eine Datei "validation.xml" und in XML-Dateien definierte Integritätsbedingungen enthalten, von der Datei "validation.xml" und den Integritätsbedingungsdateien anderer Module isoliert werden, indem für das Modul mit den XML-Deskriptoren spezielle Validator-Instanzen erstellt werden.

Erweiterte Bean-Validation-Konzepte

Die Bean Validation API stellt einen Satz integrierter Integritätsbedingungen und eine Schnittstelle bereit, mit der Sie angepasste Integritätsbedingungen deklarieren können. Dies wird durch die Erstellung von Integritätsbedingungsannotationen und die Deklaration einer Annotation in einem Beantyp, einem Beanfeld oder einer Beaneigenschaft deklariert wird. Die Erstellung von Integritätsbedingungen kann auch durch Deklaration der Integritätsbedingung in einer anderen Integritätsbedingungsdefinition erfolgen.

Im folgenden Beispiel wird die Erstellung einer CommentChecker-Integritätsbedingung veranschaulicht, die definiert wird, um sicherzustellen, dass ein Feld für eine Kommentarzeichenfolge nicht null ist. Der Kommentartext wird in eckige Klammern eingeschlossen, z. B. [Text].

package com.my.company;
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import javax.validation.Constraint;
import javax.validation.Payload;
    
@Documented
@Constraint(validatedBy = CommentValidator.class)
@Target({ METHOD, FIELD })
@Retention(RUNTIME)
public @interface CommentChecker {
       String message() default "The comment is not valid.";
       Class<?>[] groups() default {};
       Class<? extends Payload>[] payload() default {};
     	…} 
Im nächsten Beispiel wird der Integritätsbedingungsvalidator gezeigt, der die Validierung der Elemente mit der Annotation "@CommentChecker" durchführt. Der Integritätsbedingungsvalidator implementiert die Schnittstelle "ConstraintValidator", die von der Bean Validation API bereitgestellt wird.
package com.my.company;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
public class CommentValidator implements ConstraintValidator<CommentChecker, String> {
    public void initialize(CommentChecker arg0) {       
    }
    public boolean isValid(String comment, ConstraintValidatorContext context) {
        if (comment == null) {
            // Null comment is not allowed, fail the constraint. 
            return false;
        }
        if (!comment.contains("[") && !comment.contains("]")) {
            // Can't find any open or close brackets, fail the constraint
            return false;
        }
        // Ignore leading and trailing spaces
        String trimmedComment = comment.trim();
        return // validate '[' prefix condition
               trimmedComment.charAt(0) == '[' && 
               // validate ']' suffix condition
               trimmedComment.charAt(trimmedComment.length()!-1) == ']';
    }
}
Nach der Definition der Annotation "@CommentChecker" kann diese verwendet werden, um sicherzustellen, dass das Feld für die Kommentarzeichenfolge gemäß der Implementierung der CommentValidator-Methode "isValid()" ein gültiger Kommentar ist. Im folgenden Beispiel wird die Verwendung der @CommentChecker-Integritätsbedingung veranschaulicht. Bei der Validierung der Bean "myChecker" wird die Kommentarzeichenfolge von der Klasse "CommentValidator" validiert,um sicherzustellen, dass die definierten Integritätsbedingungen eingehalten wurden.
package com.my.company;
public myChecker {  

    @CommentChecker
    String comment = null; 
    ...
}

Das Produkt stellt einen speziellen Bean-Valdidation-Provider bereit, aber möglicherweise muss eine Anwendung einen anderen Provider verwenden. Sie können einen anderen Provider über das Programm auswählen, indem Sie die Methode "javax.validation.Validation.byProvider()" aufrufen, um eine Validierungsfactory zu erstellen. Alternativ dazu können Sie einen anderen Provider auswählen, indem Sie das Element <default-provider/> in der Datei "validation.xml" angeben. Wenn Sie sicherstellen möchten, dass die alternative Providerklasse zum Standardprovider nicht im Widerspruch steht, müssen Sie für die Reihenfolge der Server- bzw. Anwendungsklassenlader den Wert Mit dem lokalen Klassenlader geladene Klassen zuerst (übergeordneter zuletzt) festlegen. Weitere Informationen zu dieser Einstellung finden Sie in der Dokumentation zum Laden von Klassen.

Die Spezifikation Bean Validation legt fest, dass eine Ausnahme des Typs "ValidationException" ausgelöst wird, wenn mehrere Dateien "validation.xml" gefunden werden. WebSphere Application Server unterstützt jedoch eine Umgebung, in der mehrere Teams Module entwickeln, die dann assembliert und gemeinsam im Anwendungsserver implementiert werden. In dieser Umgebung werden alle EJB-Module in einer Anwendung mit demselben Klassenladeprogramm geladen, und es ist möglich, die Anwendungsklassenladeprogramme so zu konfigurieren, dass alle EJB- und WAR-Module von einem einzigen Klassenladeprogramm geladen werden. Deshalb bietet das Produkt Unterstützung für mehrere Dateien "validation.xml" in demselben Klassenpfad.

Wenn eine Anwendung, die Bean Validation und XML-Deskriptoren nutzt, mehrere EJB-Module und Webmodule enthält, wird jede Datei "validation.xml" einer Validation-Factory zugeordnet, die speziell für dieses Modul gilt. In dieser Umgegbung werden alle definierten Elemente "constraint-mapping" nur in dem Modul gesucht, in dem die Datei "validation.xml" definiert ist. Wenn beispielsweise eine Datei "building.jar" eines EJB-Moduls eine Datei "META-INF/validation.xml" enthält und in der Datei "validation.xml" die folgenden Integritätsbedingungen definiert sind, müssen sich die Dateien "META-INF/constraints-house.xml" und "META-INF/constraints-rooms.xml" ebenfalls in der Datei "building.jar" befinden:
<constraint-mapping>META-INF/constraints-house.xml</constaint-mapping>
<constraint-mapping>META-INF/constraints-rooms.xml</constraint-mapping>

Ausgenommen von diesem Verhalten ist der Fall, in dem alle Klassen und Konfigurationsdaten für die Bean-Validation-Integritätsbedingungen für alle Anwendungsmodule sichtbar sind. Wenn eine einzige Datei vom Typ "validation.xml" in einer EAR-Datei definiert ist und keine anderen Dateien vom Typ "validation.xml" in einem Modulklassenpfad sichtbar sind, verwendet jedes Modul, das eine Validator-Factory oder einen Validator erstellt, die Datei "validation.xml", die in der EAR-Datei definiert ist. So können andere Module eine Validatorfactory erstellen, die die Datei "validation.xml" eines anderen Moduls verwendet, solange der Klassenpfad so konfiguriert wurde, dass beide Module im selben Klassenpfad sichtbar sind und nur eine einzige Datei vom Typ "validation.xml" sichtbar ist.

Ausführlichere Informationen zu den Bean-Validation-APIs und -Metadaten finden Sie im Spezifikationsdokument JSR 349 Bean Validation.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_beanval
Dateiname:cdat_beanval.html