Hibernate Validator 4.3.0.Beta1

Moving along the road to a Hibernate Validator 4.3 release I am happy to announce the release of Hibernate Validator 4.3.0.Beta1.

One of our foci this time around was to address existing caching issues. HV-479 addresses the problem that the constraint metadata for a given class would be cached in the so called BeanMetaDataManager without a appropriate eviction policy. In most cases this should not be a problem, but for long running applications with for example hot redeploys it could be. We resolved this issue by introducing SoftLimitMRUCache which has an upper bound for the cached metadata.

HV-564 is another caching related issue. Initally ConstraintValidator instances were only cached if they where created by the Hibernate Validator specific ConstraintValidatorFactoryImpl. Now caching occurs also for a custom ConstraintValidatorFactory.

Two other interesting issues are HV-563 and HV-517. The former allows you to reuse your Configuration instance and call Configuration#buildValidatorFactory() multiple times. The latter introduces the concept of ignoring annotations to the programmatic API. In the XML configuration it has always be possible to do something like this:

<constraint-mappings
    xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd">

    <bean class="my.package.MyClass" ignore-annotations="true">
    </bean>
</constraint-mappings>

Via the programmatic API this is now possible via:

// ...
ConstraintMapping mapping = new ConstraintMapping();
mapping.type( MyClass.class ).ignoreAllAnnotations();
// ...

Of course ignoreAllAnnotations() is also available on the property level of the API.

Another important focus was on HV-561. This issue identifies the API methods which will change between Hibernate Validator 4.3 to 5 (as much as we can foresee this at the moment). Causes for these changes are Bean Validation 1.1 and the separation between API/SPI and internal packages. This has already been discussed in the previous release blog. Right now we have two new packages org.hibernate.validator.spi.group and org.hibernate.validator.spi.resourceloading containing DefaultGroupSequenceProvider and ResourceBundleLocator respectively. The old versions of these interfaces have been deprecated and will be removed in HV 5.

// not sure about the following. I think we pretty much decided that introducing 'api' breaks // to much and it hence not worth it. Still it looks damn nice ;-)

On a side note, right now we have the following packages:

org.hibernate.validator.cfg
org.hibernate.validator.constraints
org.hibernate.validator.group
org.hibernate.validator.internal
org.hibernate.validator.messageinterpolation
org.hibernate.validator.method
org.hibernate.validator.resourceloading
org.hibernate.validator.spi

Would it make sense to even have:

org.hibernate.validator.api
org.hibernate.validator.internal
org.hibernate.validator.spi

Obviously such a move would break much more client code than the current structure. Let us know what you think.

Last but not least, there are also some news from the Hibernate Validator Annotation Processor which can now be used without any additional dependencies (HV-457). This will make it easier to configure the processor within your build as well as IDE.

Hibernate Validator 4.3.0.Beta1 is available via the JBoss Maven Repository under the GAV org.hibernate:hibernate-validator:4.3.0.Beta1 or via SourceForge. The changelog is available here and make sure to check the Hibernate Validator Migration Guide as well.

Feedback is always welcome via the Validator Forum and the project issue tracker.

Enjoy!

hferentschik/gist:2293497