Help

I am a core developer on the Hibernate products Annotations, EntityManager, Search and Validator. Currently I am focusing on the implementation JSR 303 - Bean Validation.

Location: Göteborg, Sweden
Occupation: Developer at JBoss, a division of Red Hat
Archive

May I present, fresh from the roaster, steaming hot and full of flavor - Hibernate Validator 5.1.0.Final. Validator 5.0 to 5.1 was a slow roast, outspread over several releases, but as you know, slow roasting enhances the flavor ;-)

The individual release blog entries highlighted the various changes for each release. Here is just a short summary with pointers to refresh your memory.

The main goal of Hibernate Validator 5.1 was to improve performance and memory footprint after releasing the initial reference implementation for Bean Validation 1.1. We achieved both and squashed several bugs along the way. If you want to know more have a look at HV-589, HV-637, HV-838 and HV-842. In particular the CDI integration (hibernate-validator-cdi) got an overhaul. As per specification, it should be possible to use multiple Bean Validation providers within CDI, selecting between them using qualifiers. In particular something like this should be possible:

...
@HibernateValidator
@Inject
Validator validator;

@Inject
Validator defaultValidator;
...
where the default Validator instance is not Hibernate Validator, but an explicitly via validation.xml configured provider:
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
                   xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <default-provider>com.acme.ValidationProvider</default-provider>
</validation-config>
Due to a bug this was not working, but now it is :-) See HV-858 and HV-865 for more information.

We also added a couple of new features. The most important one is the introduction of the ValidatedValueUnwrapper SPI. Refer to the Beta1 blog entry for more details. There are also a few new constraints. You can now make use of @Mod10Check, @Mod11Check (which are effectively replacing the now deprecated @ModCheck constraint) and @EAN (see CR1 blog entry). A feature related to the ParameterNameProvider introduced by Bean Validation 1.1 is the ability to use ParaNamer as parameter name provider (see HV-802).

Maven artifacts are as usual on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.Final and distribution bundles are available on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If you want to know where we are heading next, check out the Hibernate Validator Roadmap.

Don't wait, upgrade!

I am happy to announce Hibernate Validator 5.1.0.CR1, hopefully (fingers crossed) the last release prior Final. We used the release for last adjustments and some bug fixes.

On the bug fix side, we addressed issues with the CDI integration (HV-858), EL message interpolation (HV-834) and validated value unwrapping in conjunction with Validator#validateValue and Validator#validateProperty (HV-860).

We also gave @Mod10Check and @Mod11Check a final overhaul and made the parameter naming more consistent and changed the semantics of startIndex, endIndex and checkDigitIndex. They are now all inclusive and always relative to the original validated value, indepent of ignoreNonDigitCharacters. If you are already using these new constraints, I recommend you review the linked Javadocs to understand the updated semantics.

Last but not least, we added yet another checksum related constraint - @EAN. It allows you to validate International Article Numbers (EAN-13 and EAN-8).

The full change log can be found here. Maven artefacts are on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.CR1 and distribution bundles are available on SourceForge.

Feedback and questions are always welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.

Enjoy!

This is just a quick note that the Hibernate Metamodel Generator code has moved and is now, as of version 4.3.0.Final, part of Hibernate ORM. You can find it in the tooling/metamodel-generator sub-directory of ORM. Unfortunately this news have been falling under the table during the announcement of ORM 4.3.0.Final. After all the focus was on JPA 2.1 support :-)

There are several reasons for the move. For one, we hope that the generator will get a greater exposure within the ORM code-base and that it will benefit from the more regular ORM release schedule. For another, the generator fitted nicely into the newly created collection of Hibernate ORM tooling artifacts (check for example the maven/gradle plugins for byte code enhancement). Code wise nothing has changed. The annotation processor is still agnostic of the JPA provider and can be used with any provider to generate the metamodel classes for type-safe criteria queries. So what has changed:

Enjoy!

It has been a while since the first alpha release of Validator 5.1, but as the saying goes: Haste makes waste :-) There is a lot going on in the Hibernate universe and over the last few months we have been especially busy with projects like Search and OGM. Not to speak of the new Hibernate website. Sigh, if we just had more contributors lending a hand (hint, hint).

Nevertheless, we found time to also work on Validator and the result is Hibernate Validator 5.1.0.Beta1 with some nice new features and bug fixes. The most notable feature is the introduction of @UnwrapValidatedValue and the corresponding ValidatedValueUnwrapper SPI (see HV-819). The idea is that in some cases the value to validate is contained in a wrapper type and one would have to add custom ConstraintValidator implementations for each constrained type and constraint. Think Java 8 Optional or JavaFX Property types. For example in JavaFX you could have:

@NotBlank
@UnwrapValidatedValue
private Property<String> name = new SimpleStringProperty( "Foo" );
Here the intention is to apply the @NotBlank constraint to the string value, not the the Property instance. By annotating name with @UnwrapValidatedValue the Validator engine knows that it has to unwrap the value prior to validation. To be able to do this, you need to also register an implementation of ValidatedValueUnwrapper which specifies how this unwrapping has to happen. You can do this via validation.xml as provider specific property (hibernate.validator.validated_value_handlers) or programmatically via:
Validator validator = Validation.byProvider( HibernateValidator.class )
        .configure()
        .addValidatedValueHandler( new PropertyValueUnwrapper() )
        .buildValidatorFactory()
        .getValidator();
PropertyValueUnwrapper is in this case an implementation of ValidatedValueUnwrapper which tells the Validator engine how to unwrap a Property type and of which type the validated value is. The latter is needed for constraint validator resolution. For more information refer to the online documetnation.

What else is worth mentioning? Thanks to Brent Douglas for profiling of Hibernate Validator and detecting of some potential memory leaks - see HV-838 and HV-842. They are fixed now.

Thanks also to Victor Rezende dos Santos and Shin Sang-Jae. Victor found a problem with the Brazilian CPF constraint which lead to its refactoring HV-808, as well as the deprecation of @ModCheck and the introduction of dedicated @Mod10 and @Mod11 constraints as replacements. Shin on the other hand provided a Korean translation of the ValidationMessages properties bundle.

Last but not least, we also have an improved the memory footprint by reducing the amount of memory consumed by metadata (HV-589).

In total 29 resolved issues. Not bad in my opinion and definitely worth upgrading to Validator 5.1.

Maven artefacts are on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.Beta1 and distribution bundles are available on SourceForge. Send us feedback either via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.

Enjoy!

Guillaume pointed out recently on the hibernate-dev mailing list that is has been a very long time since the last release of Hibernate JPA Metamodel Generator release and that it is time to do another one. And we listened. We just released 1.3.0.Final. As usual, you can get the artefacts from the JBoss Maven repo or from SourceForge.

Don't say that we are not listening to our users and contributors. There might have been, however, some self interest in Guillaume's request. After all he reported three of the 10 resolved issues and even contributed patches to fix them. Thanks for your help! To single out one of the 10 issues, it should be METAGEN-92. Its fix will make sure that the annotation processor will now also work with JPA 2.1 configuration files (persistence.xml and orm.xml).

In case you forgot how to setup the annotation processor in Maven have a look at this post and don't forget to report any issues in the Hibernate JIRA project METAGEN.

Enjoy!

Showing 1 to 5 of 53 blog entries