Red Hat

In Relation To Releases

In Relation To Releases

We just published Hibernate Search version 5.8.0.Beta1, which is now compatible with Elasticsearch versions 5.x.

New improved Elasticsearch client

This release now uses the new Elasticsearch REST client, which is expected to be a safe choice in terms of long term maintenance as it’s sponsored and recommended by the Elasticsearch team.

Compared to the driver we used previously, this one uses a state of the art reactive architecture, so we can take advantage of more efficient resource utilization.

Elasticsearch 2.x is still supported

The new driver is backwards compatible, so we’ll still be able to connect to clusters running Elasticsearch 2.x.

This doesn’t need any configuration flag as Hibernate Search can automatically detect the version of Elasticsearch it’s being pointed to.

The features supported by Elasticsearch 5.x and 2.x are however slightly different and you’ll find that some low level mapping features are documented as compatible with only one specific version.

The migration guide will be updated when this minor release will be feature complete.

New Simple Query String supported by the Query builder DSL

The useful capabilities from Lucene’s SimpleQueryParser are now conveniently exposed by our higher level DSL.

We’ll publish a detailed blog about this new feature soon: stay tuned!

If you can’t wait, we won’t prevent you from peeking into the Simple Query String documentation.

Simplified JNDI configuration

If you integrated any external component into Hibernate Search using JNDI, for example a JMS queue or an Infinispan cache, this configuration was simplified.

You will no longer need to set Hibernate Search specific configuration properties such as how to set the InitialContext for JNDI lookups: only configure Hibernate ORM, and Hibernate Search will inherit the same settings.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback

Feedback always welcome!

Please let us know of any problem or suggestion by creating an issue on JIRA, or by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

Tenth bug-fix release for ORM 5.2

Posted by    |       |    Tagged as Hibernate ORM Releases

The Tenth bug-fix release for Hibernate ORM 5.2 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.2.10

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

The release bundles can be obtained from SourceForge or BinTray.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. This Alpha2 release is coordinated with the 2.0.0.Alpha2 release of the Bean Validation specification.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

If you missed the Alpha1 release, consulting its announcement might be beneficial to you before continuing your reading.

What’s new since Alpha1

Improved container element validation support

Container element validation support is the big new feature of Bean Validation 2.0 and it got some more love during this cycle.

Programmatic API and XML support

To obtain the equivalent of:

public class FishTank {

    private Optional<@Valid FishTankModel> model;

    private Map<@Size(min = 3, max = 10) String, @Min(1) Integer> fishCountByType;
}

it is now possible to declare container element type constraints and cascaded validation either via an XML mapping configuration (which is part of the Bean Validation 2.0 specification):

[...]
    <bean class="com.acme.FishTank" ignore-annotations="false">
        <field name="model">
            <containerElementType>
                <valid />
            </containerElementType>
        </field>
        <field name="fishCountByType">
            <containerElementType typeArgumentIndex="0">
                <constraint annotation="javax.validation.constraints.Size">
                    <element name="min">
                        <value>3</value>
                    </element>
                    <element name="max">
                        <value>10</value>
                    </element>
                </constraint>
            </containerElementType>
            <containerElementType typeArgumentIndex="1">
                <constraint annotation="javax.validation.constraints.Min">
                    <element name="value">
                        <value>1</value>
                    </element>
                </constraint>
            </containerElementType>
        </field>
    </bean>
[...]

or via the (implementation specific) programmatic API:

ConstraintMapping newMapping = config.createConstraintMapping();
newMapping
    .type( FishTank.class )
        .property( "model", FIELD )
            .containerElementType()
                .valid()
        .property( "fishCountByType", FIELD )
            .containerElementType( 0 )
                .constraint( new SizeDef().min( 3 ).max( 10 ) )
            .containerElementType( 1 )
                .constraint( new MinDef().value( 1 ) );

Other improvements

We also made a couple of more minor improvements:

  • the TYPE_ARGUMENT node type has been renamed to CONTAINER_ELEMENT (type argument don’t make sense for annotated array elements)

  • we allow per context custom value extractors

  • we allow value extractors to be contributed using the service loader mechanism

  • we allow to specify value extractors using XML configuration

  • we explore the parent classes and interfaces to search the ValueExtractor definition

Support for the new constraints added to Bean Validation 2.0

In the Alpha2 release of Bean Validation 2.0, we introduced the following new constraints:

  • @NotBlank: check that a char sequence is not blank (i.e. not null, and length of trimmed char sequence > 0)

  • @NotEmpty: check that an element (char sequence, collection, array) is not null and not empty

  • @Email: check that a char sequence is a valid email

  • @Positive: check that a number is positive

  • @Negative: check that a number is negative

We added support for these new constraints to Hibernate Validator.

Performance improvements

We started to run a few benchmarks on Hibernate Validator 6 and we fixed a few performance regressions.

6.0.0.Alpha2 is now significantly faster than 5.4, mostly thanks to the new ValueExtractor design.

Getting 6.0.0.Alpha2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

Hibernate Validator 5.4.1.Final

Posted by    |       |    Tagged as Hibernate Validator Releases

A bugfix release

Hibernate Validator 5.4.1.Final is a bugfix release, mostly for corner cases. 5.4.1.Final is a recommended upgrade for everyone.

Here are the most prominent bugfixes of this release:

  • HV-1088 - Fix a concurrency issue in validator initialization that you probably wouldn’t encounter in a normal usage - you’re supposed to use a shared ConstraintValidatorFactory which mitigates the issue

  • HV-1280 - Fix a class loading conflict with Xerces in modular environements (e.g. WildFly)

  • HV-1252 - Fix an issue with the annotation processor and JavaMoney support. Thanks go to Guillaume Husta for this one.

  • HV-1253 - A few TYPE_USE mentions had been mistakenly introduced in 5.4 when backporting from 6 (5.4 still supports Java 6)

We also integrated a new translation, Persian, thanks to Shahram Goodarzi.

And finally, we upgraded our build instructions for the latest JDK 9 early access build.

As usual, you can find the complete list of all addressed issues in the change log.

Getting 5.4.1.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.1.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are under active development. We will release a new alpha in the next few days.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

Ninth bug-fix release for ORM 5.2

Posted by    |       |    Tagged as Hibernate ORM Releases

The Ninth bug-fix release for Hibernate ORM 5.2 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.2.9

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

The release bundles can be obtained from SourceForge or BinTray.

Hibernate ORM 5.1.5.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases

We decided to do another release of the 5.1 series to fix critical bugs to be included in an upcoming version of WildFly. This may be the last release of the 5.1 series, so we recommend that you migrate to 5.2 for future bugfixes.

Hibernate ORM 5.1.5.Final:

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

Hibernate OGM 5.1 Final is out

Posted by    |       |    Tagged as Hibernate OGM Releases

I’m happy to announce the latest stable release of Hibernate OGM: Hibernate OGM 5.1 Final

Compared to the latest candidate release, there are not many changes. You can have a look at the 5.1.0.Final changelog to get all the details.

What’s new compared to 5.0 Final?

I’m glad you asked, this version:

If you need to upgrade from a version before 5.1, you can find help on the migration notes.

Does it work with WildFly 10?

Yes, it does.

However, WildFly 10 ships with Hibernate ORM 5.0 and there are a couple of configuration steps to make it work. The easiest way is to download the WildFly modules for Hibernate ORM and Hibernate OGM ; unpack them in the modules folder of your WildFly base directory and set the following property in your persistence.xml:

<property name="jboss.as.jpa.providerModule" value="org.hibernate:5.1"/>

If you are still confused about the process, we explain it with more details in the paragraph 4.5.1. Packaging Hibernate OGM applications for WildFly 10 of the documentation.

Where can I get it?

You can get the required core library using the following Maven coordinates:

  • org.hibernate.ogm:hibernate-ogm-core:5.1.0.Final

and these are the backends currently available for 5.1.0.Final:

  • Cassandra: org.hibernate.ogm:hibernate-ogm-cassandra:5.1.0.Final

  • CouchDB: org.hibernate.ogm:hibernate-ogm-couchdb:5.1.0.Final

  • Infinispan

    • Embedded: org.hibernate.ogm:hibernate-ogm-infinispan:5.1.0.Final

    • Remote: org.hibernate.ogm:hibernate-ogm-infinispan-remote:5.1.0.Final

  • Ehcache: org.hibernate.ogm:hibernate-ogm-ehcache:5.1.0.Final

  • MongoDB: org.hibernate.ogm:hibernate-ogm-mongodb:5.1.0.Final

  • Neo4j: org.hibernate.ogm:hibernate-ogm-neo4j:5.1.0.Final

  • Redis: org.hibernate.ogm:hibernate-ogm-redis:5.1.0.Final

Alternatively, you can download archives containing all the binaries, source code and documentation from Sourceforge.

What’s next?

One of the focus of the next release will be to improve the features supported by the Hot Rod dialect.

How can I get in touch?

You can find us through the following channels:

We are looking forward to hearing your feedback!

You asked for it, we deliver: Hibernate Search 5.7.0.Final, with support for Hibernate ORM 5.2.8, is out! And of course, like previous versions, it features experimental support for Elasticsearch integration (even with some improvements).

Stuck on an older ORM version? Don’t worry, we also released a bugfix version for 5.6, namely 5.6.1.Final.

Hibernate Search 5.7.0.Final is only compatible with Hibernate ORM 5.2.3 and later. There isn’t any version of Hibernate Search compatible Hibernate ORM 5.2.0 to 5.2.2.

If you need to use Hibernate ORM 5.0.x or 5.1.x and cannot upgrade, please use Hibernate Search 5.6.1.Final.

What’s new on 5.7 since the candidate release?

Below are the main changes since the candidate release.

If you are looking for advice on how to migrate, please refer to the migration guide.

For a full list of changes since 5.7.0.CR1, please see the release notes. For a full list of changes since 5.6.0.Final, please see this list of tickets on our JIRA instance.

General improvements

  • HSEARCH-2574: when it makes sense, you can now repeat Hibernate Search annotations on a single attribute/method. For example, if you want to add two index fields on the same title attribute, you can write:

        @Field(analyzer = @Analyzer(definition = "myAnalyzer")
        @Field(name = "title_sort", analyzer = @Analyzer(definition = "myAnalyzerForSort")
        private String title;

    Thus you don’t have to use the composite annotations (@Fields) anymore. But of course, those are still available.

  • HSEARCH-2588: some methods in the Sort DSL allowed to specify the sort field type explicitly, which was useful when sorting on fields added through custom field bridges. We improved support for MetadataProvidingFieldBridge, so that you now only need to implement this interface on your custom field bridges, and won’t need anything special when using the sort DSL anymore. As a result, the byField(String, SortField.Type) and andByField(String, SortField.Type) methods in the sort DSL have been deprecated.

  • HSEARCH-2587: an NPE could occur when using the Sort DSL to sort on embedded (@IndexedEmbedded) fields; this is now fixed.

  • HSEARCH-2576: unnecessary memory allocations within queries have been removed, resulting in better query throughput.

  • And several improvements for other solutions integrating Hibernate Search, like HSEARCH-2597, HSEARCH-2561, HSEARCH-2418 or HSEARCH-2585.

Elasticsearch-specific improvements

  • HSEARCH-2453: Elasticsearch authentication is now fully implemented: there are dedicated username and password properties so that you don’t need to embed the credentials in the URL anymore.

  • HSEARCH-2593: when using automatic node discovery on Elasticsearch, a scheme (HTTP or HTTPS) cannot be detected automatically for newly discovered nodes; by default it is HTTP. You can now customize this to use HTTPS instead: just add hibernate.search.default.elasticsearch.discovery.default_scheme https to your configuration.

  • HSEARCH-2590: queries using pagination could allocate too much memory in certain circumstances; this is now fixed.

What’s new on 5.6?

5.6.1.Final contains exclusively backported fixes from 5.7. You can see a full list of changes since 5.6.0.Final in the release notes.

What’s next?

We’re now focusing on the next two big improvements:

  • support for Elasticsearch 5 without losing support for Elasticsearch 2 (HSEARCH-2434, HSEARCH-2581). This will be in a 5.8 release.

  • streamlining our APIs, in particular to better fit remote indexing services (like Elasticsearch), but also to support Lucene 6. Due to the breaking changes this requires, we will include these changes in a new major release, Hibernate Search 6.0.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Final</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.7.0.Final</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Eighth bug-fix release for ORM 5.2

Posted by    |       |    Tagged as Hibernate ORM Releases

The Eighth bug-fix release for Hibernate ORM 5.2 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.2.8

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

The release bundles can be obtained from SourceForge or BinTray.

It is not every day that we announce the first release of a new major version of Hibernate Validator. And today is one of those days: the first alpha of Hibernate Validator 6 has just been released.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. That’s why we coordinated the releases of the first alphas of these two projects.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new

New group id

First, starting from 6, the new home of Hibernate Validator is org.hibernate.validator (it used to be org.hibernate).

For instance, the Maven coordinates of this version are:

<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.0.0.Alpha1</version>
</dependency>

We published relocation artifacts to make the transition more smooth. Examine the output of your build, if you see messages like "[WARNING] The artifact org.hibernate:hibernate-validator:jar:6.0.0.Alpha1 has been relocated to org.hibernate.validator:hibernate-validator:jar:6.0.0.Alpha1", you are still using the old GAV coordinates and should upgrade to the new ones.

Also make sure to not depend on 5.x and 6.x at the same time (as the group ids are different, the dependency resolution algorithm of your build tool fails to detect that these are two versions of the same logical artifact).

Java 8 goodness

As we now target Java 8 and above, we benefit from the language improvements:

  • all Bean Validation and Hibernate Validator constraints can be used in type use context (e.g. List<@NotBlank String>);

  • all the annotations that could be repeated with a List container are now marked @Repeatable.

Implementation of the new features of the spec

Earlier this week, Gunnar presented on the Bean Validation website the new features introduced in Early Draft 1 of Bean Validation 2.0. They are implemented in Hibernate Validator 6.0.0.Alpha1 so you can already play with them and give us your feedback.

Nested type use constraints and nested cascaded validation

There are some things where Hibernate Validator goes beyond the Early Draft 1 of the spec.

Typically, with Hibernate Validator, type use constraints may be used even on nested types. And so may cascaded validation.

public class Order {

        private Map<@NotNull @Valid Product, @Size(min = 1) List<@NotNull @Valid OrderLine>> lines;

}

In the above example, Hibernate Validator is going to:

  • validate the @NotNull constraint on Product;

  • cascade the validation to Products;

  • validate that for a Product, the list of OrderLines contains at least one element;

  • validate that the lists do not contain any null element;

  • cascade the validation to OrderLines.

As mentioned above, the nested part is new in Hibernate Validator and is not part of the spec yet. If you think it should go in, raise your hand and participate to the discussions. Expect some interesting discussions soon on what the nodes of the property path should look like in the case of nested types validation.

Lambda based constraint definition

We started to explore how lambdas could be integrated into Hibernate Validator and the first outcome of it is lambda based constraint definition. Using the programmatic API, you can define a constraint without writing a ConstraintValidator:

HibernateValidatorConfiguration configuration = Validation
    .byProvider( HibernateValidator.class )
    .configure();

ConstraintMapping constraintMapping = configuration.createConstraintMapping();

constraintMapping
    .constraintDefinition( ValidPassengerCount.class )
        .validateType( Bus.class )
            .with( b -> b.getSeatCount() >= b.getPassengers().size() );

Note that the programmatic API is not part of the specification so, for now, this part is specific to our implementation.

Validation of Duration

In Hibernate Validator 6, we are able to validate a lot more java.time classes and Marko recently introduced support for Duration.

Here is an example of what you can do with it:

public class TrainingSession {
    [...]

    @DurationMin(hours = 1, minutes = 30)
    @DurationMax(days = 1, inclusive = false)
    private Duration duration;

    [...]
}

Again, let us know if you think this feature should go into the spec.

Getting 6.0.0.Alpha1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha1. As mentioned earlier, the group id has been changed to org.hibernate.validator.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

back to top