The dust is settling around JSR-303 and we are happy to release Hibernate Validator 4.0.0.CR1. With this release we will be going into feature freeze, especially since we aligned it with JBoss AS 5.2 and Glassfish for integration.

Most of the work since Beta3 was spend on completing the Bean Validation TCK and ensuring that we cover all the assertions from the specification. We are really happy that we managed to create a TCK with readable and easy to understand tests. In fact, the TCK is an excellent source for usage examples. You can read more about the TCK on the Bean Validation TCK wiki page.

Regarding the actual changes to the Hibernate Validator codebase refer to the Jira release notes. From the changes listed there the following are worth mentioning seperately:

• Hibernate Validator is now able to run in an environment with enabled SecurityManager (HV-171)
• The package structure has changed from org.hibernate.validation to org.hibernate.validator
• And the main Provider class name has changed from HibernateValidatorProvider to HibernateValidator

Refer to the Hibernate Validator Migration Guide to see what this means for you.

JBoss AS 5.2 beta is around the corner and it will have Bean Validation (Hibernate Validator) inside. Things are really coming together :)

Enjoy!

With work on version 3.2 of Hibernate Search well underway and a range of very interesting features in the pipeline (eg programmatic configuration API, bulk indexing and dynamic boosting), we decided to provide some of the bug fixes also for the 3.1 version of Hibernate Search. Hence here is Hibernate Search 3.1.1 GA. On top of several bug fixes which are listed in the release notes we also upgraded Lucene from 2.4 to 2.4.1.

We recommend users of version 3.1 to upgrade to 3.1.1 to come into the benefits of these bug fixes.

You can download the release here.

enjoy!

The first beta version of Hibernate Validator - 4.0.0 Beta1 - is now available. This version is based on JSR 303 Specification 1.0.CR2[1].

New in this release is the ability to configure Hibernate Validator via XML (see section 7 of the specification[1]). There are two types of configuration files. Firstly, validation.xml which allows to programmatically configure your Bean Validation framework. Here is an example, which specifically states the Bean Validation Provider and message interpolator. It also specifies the location of further mapping files:

<?xml version="1.0" encoding="UTF-8"?>
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
    xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <default-provider>org.hibernate.validation.engine.HibernateValidatorConfiguration</default-provider>
    <message-interpolator>org.hibernate.validation.engine.ResourceBundleMessageInterpolator</message-interpolator>
    <constraint-mapping>META-INF/validation/order-constraints.xml</constraint-mapping>
    <constraint-mapping>META-INF/validation/user-constraints.xml</constraint-mapping>
    <property name="org.hibernate.validator.test">foobar</property>
</validation-config>

The second type of XML configuration files are the actual mapping file which let you declare constraints declarations. The XML matches closely the annotation declaration approach. user-constraints.xml as used in the above example could look like this:

<constraint-mappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                     xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd"
                     xmlns="http://jboss.org/xml/ns/javax/validation/mapping">
    <default-package>org.hibernate.validation.engine.xml</default-package>
    <bean class="User" ignore-annotations="false">
        <class ignore-annotations="true">
            <group-sequence>
                <value>User</value>
                <value>Optional</value>
            </group-sequence>
            <constraint annotation="org.hibernate.validation.engine.xml.ConsistentUserInformation">
                <message>Message defined in xml</message>
                <groups>
                    <value>javax.validation.groups.Default</value>
                </groups>
                <element name="stringParam">foobar</element>
            </constraint>
        </class>
        <field name="lastname">
            <constraint annotation="javax.validation.constraints.Pattern">
                <message>Last name has to start with with a capital letter.</message>
                <element name="regexp">^[A-Z][a-z]+</element>
            </constraint>
        </field>
        <field name="creditcard">
            <valid/>
        </field>
        <getter name="firstname" ignore-annotations="true">
            <constraint annotation="javax.validation.constraints.Size">
                <message>Size is limited!</message>
                <groups>
                    <value>org.hibernate.validation.engine.xml.TestGroup</value>
                    <value>javax.validation.groups.Default</value>
                </groups>
                <element name="max">30</element>
            </constraint>
        </getter>
    </bean>
    <constraint-definition annotation="org.hibernate.validation.engine.xml.ConsistentUserInformation">
        <validated-by include-existing-validators="false">
            <value>org.hibernate.validation.engine.xml.CustomConsistentUserValidator</value>
        </validated-by>
    </constraint-definition>
</constraint-mappings>

with a matching User entity of :

public class User {

	private String firstname;
	private String lastname;
	private CreditCard creditcard;
	private String phoneNumber;

        // standard getter and setter follow
        ...
}

This first beta release is nearly feature complete now, except some minor discrepancies between implementation and specification due to ongoing specification work. We are aiming at least one more beta release to completely align implementation and specification. Work on this has already started and the outcome will be a Bean Validation TCK. The foundation for the TCK is build on the JSR 299 TCK framework. Thanks guys ;-) Of course we will also try to complete our reference documentation as fast as possible.

Any feedback for the release is welcome.

Enjoy!

Hibernate Validator version 4.0.0 Alpha3 is of now available. This implementation is based on JSR 303 Specification 1.0.CR1[1]. The distribution packages contain everything you need to get started.

As promised in the last post implicit grouping is now available. On top of this the metadata API is now in sync with the current spec and there is a JPA 2 aware TraversableResolver. @Valid supports now Iterables and the cascading algorithm follows the new graph navigation rules. In the previous releases an object instance would only be validated once per group. Now this instance can be validated once per group AND validation path. Lets look at the object graph below to illustrate the change:

Assuming a @NotNull constraint on Address.addressLine validating the shown Order instance against the default group will now result in three ConstraintViolations differing only in the property path. The paths are:

• shippingAddress.addressline1
• customer.addresses[0].addressline1
• billingAddress.inhabitant.addresses[0].addressline1

Previously only one ConstraintViolation would have returned and it was not defined which property path it would contain. Last but not least the ConstraintValidator resolution algorithm got revamped and works now with generics. This allows support for constructs like:

@MyConstraint
Collection<? extends Number> element;

For further information about this release refer to the Jira change log and please provide us with some feedback.

Enjoy!

Following the Roadmap version 4.0.0 Alpha2 of Hibernate Validator is now available. This implementation is based on JSR 303 Specification 1.0.Beta4[1]. The distribution contains everything you need to get started. If not let us know what you are missing.

The main focus for this release was to implement groups, group sequences and the redefinition of the Default group for a class. Implicit grouping will be available in the next release. Next to the grouping feature ConstraintValidatorContext and TraversableResolver are now properly integrated in the implementation and all builtin constraints as per current spec are also supported.

Naturally there were also several unrelated bug fixes, especially around the methods Validator.validateValue and Validator.validateProperty. Check the change log if you want to know more.

It would be great if you could try out this release and provide us with some feedback.

Enjoy!