valdr Bean Validation

Bean Validation (JSR 303) plugin for valdr, the new AngularJS Model Validator.

• Offering
• Features
• Use
  • CLI client
  • Servlet
• Dependency on valdr
• Mapping of Bean Validation constraints to valdr constraints
• Including validation group information in the generated JSON
• Support
• License

Offering

valdr Bean Validation parses Java model classes for Bean Validation constraints (aka JSR 303 annotations) and extracts their information into a JSON document to be used by valdr. This allows to apply the exact same validation rules on the server and on the AngularJS client.

Features

• offline use: CLI client which can be integrated into build process to produce static valdr JSON which is packaged and delivered with the web application
• online use: Servlet which parses model classes at runtime and sends JSON back to AngularJS client (e.g. during client start or on-demand)
• both Servlet and CLI client support a number of config options
  • list of packages to scan
  • list of classes in those packages to exclude
  • list of fields to exclude
  • list of custom annotation classes to include in JSON
  • whether to output simple or full type names
  • the output file name (CLI only)
  • CORS Access-Control-Allow-Origin HTTP header value (Servlet only)
  • whether to output JSR-303 validation groups
  • which packages to scan for validation group marker interfaces
• Servlet offers built-in CORS support

Use

Check out the demo for usage samples of both CLI client and Servlet.

<dependency>
  <groupId>com.github.valdr</groupId>
  <artifactId>valdr-bean-validation</artifactId>
  <version>see-latest-version-at-the-top-of-this-page</version>
</dependency>

CLI client

Example of Maven integration:

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <version>${exec-maven-plugin.version}</version>
      <executions>
        <execution>
          <id>process-bean-validation-annotations</id>
          <phase>process-classes</phase>
          <goals>
            <goal>java</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <mainClass>com.github.valdr.cli.ValdrBeanValidation</mainClass>
        <arguments>
          <!-- optional, if omitted valdr-bean-validation.json is expected at the root of the class path -->
          <argument>-cf</argument>
          <argument>my-config.json</argument>
          <!-- optional, overrides any 'outputFile' which may have been set in the above config file -->
          <argument>-outputFile</argument>
          <argument>${basedir}/src/main/webapp/validation/validation.json</argument>
        </arguments>
      </configuration>
    </plugin>
  </plugins>
</build>

Servlet

Example of web.xml:

<servlet>
  <servlet-name>valdr Bean Validation Servlet</servlet-name>
  <servlet-class>com.github.valdr.ValidationRulesServlet</servlet-class>
  <!-- if omitted valdr-bean-validation.json is expected at the root of the class path -->
  <init-param>
    <param-name>configFile</param-name>
    <param-value>my-config.json</param-value>
  </init-param>
</servlet>

Dependency on valdr

valdr Bean Validation is dependent on valdr in two ways:

• JSON structure is defined by valdr
• validators listed in the JSON document have to be either a [supported valdr valdidator] (https://github.com/netceteragroup/valdr#built-in-validators) or one of your custom JavaScript validators

To indicate which valdr version a specific valdr Bean Validation version supports there's a simple rule: the first digit of the valdr Bean Validation version denotes the supported valdr version. Version 1.x will support valdr 1. This means that valdr Bean Validation 1.x+1 may introduce breaking changes over 1.x because the second version digit kind-of represents the "major" version.

Mapping of Bean Validation constraints to valdr constraints

The BuiltInConstraint.java enum defines the mapping of Bean Validation constraints to valdr constraints.

Bean Validation	valdr	Comment
NotNull	required
Min	min
Max	max
Size	size
Digits	digits
Pattern	pattern	Java regex pattern is transformed to JavaScript pattern
Future	future
Past	past
Email	email	proprietary Hibernate Validator (not in Bean Validation spec)
URL	url	proprietary Hibernate Validator (not in Bean Validation spec)

Including validation group information in the generated JSON

Validation groups allow you to enforce a different set of validation constraints in different situations.

To generate group information set the following two parameters:

• outputValidationGroups: true
• validationGroupPackages: []

The generated JSON will include for each constraint the value of the groups attribute of the constraint with the inheritance hierarchy of the validation group marker interfaces expanded. If a constraint does not have the groups attribute specified, the default value is considered to be javax.validation.Default.class, and the groups array in the generated JSON will contain "Default" and all your interfaces extending javax.validation.Default and belonging to one of the packages in validationGroupPackages.

When given

public interface Draft extends Default {
}
public interface Published extends Draft {
}
...
@NotNull
private String mandatoryForAll;

@NotNull(groups = Draft.class)
private String mandatoryForDraft;

@NotNull(groups = {Published.class})
private String mandatoryForPublished;

The generated JSON will include

mandatoryForAll:
  required:
    groups: ["Published", "Draft", "Default"]
...
mandatoryForAll:
  required:
    groups: ["Published", "Draft"]
...
mandatoryForPublished:
  required:
    groups: ["Published"]

Support

Ask a question on Stack Overflow and tag it with valdr-bean-validation.

License

MIT © Netcetera AG