Red Hat

In Relation To Releases

In Relation To Releases

Hibernate ORM 5.1.10.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases

We decided to do another release of the 5.1 series to fix some 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.10.Final:

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

We just published Hibernate Search version 5.8.0.CR1, with bugfixes and improvements over 5.8.0.Beta4.

Version 5.8.0.CR1 is the last opportunity for the community to test it and report bugs before the release.

Hibernate Search 5.8.x, just as 5.7.x, is only compatible with Hibernate ORM 5.2.3 and later.

If you need to use Hibernate ORM 5.0.x or 5.1.x, use the older Hibernate Search 5.6.x.

What’s new in CR1?

Here are the most notable changes:

  • HSEARCH-2831: request signing for Amazon’s proprietary IAM authentication mechanism now requires you to set the hibernate.search.default.elasticsearch.aws.signing.enabled property to true, allowing you to easily disable signing even if the hibernate-search-elasticsearch-aws JAR is in your classpath.

  • HSEARCH-2818 / HSEARCH-2821: sending requests to Elasticsearch is now much less memory-consuming.

  • HSEARCH-2764: we improved the orchestration of index updates before they are sent to the Elasticsearch client:

    • Index updates originating from a single Hibernate Search node will now be sent to Elasticsearch in the order they were generated, even when they come from different threads.

    • Mass indexing will now add documents in parallel, allowing you to take advantage of having multiple connections to the Elasticsearch cluster. Note you can customize the maximum number of connections using the hibernate.search.default.elasticsearch.max_total_connection and hibernate.search.default.elasticsearch.max_total_connection_per_route configuration properties.

    • The internal index update queues are now bounded, thus performing mass indexing on very large data sets will not trigger an OutOfMemoryError anymore.

    • We also made several other internal changes to improve performance (less Refresh API calls, more request bulking, …​).

  • HSEARCH-2839: when using a metadata-providing bridge, the bridge can now implement projection on the default field even if its type was set to OBJECT.

  • HSEARCH-2840: when using a metadata-providing bridge, the bridge can now implement projection on dynamic fields.

  • HSEARCH-2843: changing the limit/offset of a query now properly clears the query’s result cache with Elasticsearch.

For a full list of changes since 5.8.0.Beta4, please see the release notes.

How to get this release

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.CR1</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.CR1</version>
</dependency>

To use Amazon’s proprietary IAM authentication mechanism to access your Elasticsearch cluster you’ll also need:

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

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

It has been a long ride, more than six months, but here it is: we just released Hibernate Validator 6.0 Final together with the final version of the Bean Validation 2.0 specification.

What’s new since CR3?

For those who have followed closely the development of 6.0, here are the important changes since CR3:

  • Updated documentation

  • Updated translations

  • Performance improvements

  • Reduced memory footprint

  • Support for the latest JDK 9 (build 180)

The complete list of fixed issues can be found on our JIRA.

Why should I use this nifty new version?

We have some new features for you

First and foremost, Hibernate Validator 6.0 is the Reference Implementation of the Bean Validation 2.0 specification so it comes with all its new features:

  • First class support of container element constraints and cascaded validation (think private Map<@Valid @NotNull OrderCategory, List<@Valid @NotNull Order>> orderByCategories;);

  • Support for the new JSR 310 date/time data types for @Past and @Future;

  • New built-in constraints: @Positive, @PositiveOrZero, @Negative, @NegativeOrZero, @PastOrPresent and @FutureOrPresent;

We also have leveraged the new features of JDK 8 (built-in constraints are marked repeatable, parameter names are retrieved via reflection) as it is now the minimal version required.

You can read the whole story in the announcements of our Alpha, Beta and Candidate releases:

  • 6.0.0.Alpha1 in which we introduced nested container elements support and lambda based constraint definitions;

  • 6.0.0.Alpha2 with programmatic API and XML definition for container elements;

  • 6.0.0.Beta1 with metadata retrieving support for container elements;

  • 6.0.0.Beta2 with support for non generic container types in value extraction;

  • 6.0.0.CR1, 6.0.0.CR2 and 6.0.0.CR3 where we polished the features and the API.

It’s faster…​

We have done quite a lot of benchmarking and have significantly improved the performances of Hibernate Validator. It can be up to two times faster in various scenarios.

We’re going to publish the results of our benchmarks on this blog soon.

…​and it consumes less memory!

To do its magic, Hibernate Validator collects a lot of metadata on your constrained beans. After a report from the Keycloak developers, we worked on reducing the memory footprint used by the collected metadata.

Hibernate Validator should now consume significantly less memory than before to store your constrained beans' metadata.

Easy upgrade

The first thing you’ll notice is that the groupId of the artifact has changed: it is now org.hibernate.validator (we added validator at the end to better compartimentalize the various Hibernate technologies).

Other than that, it will probably just be a drop-in replacement if you didn’t use experimental features.

If you used the old value handling infrastructure to deal with custom containers, you need to migrate them to the new value extractor infrastructure.

The detailed list of potential migration concerns can be found in our migration guide.

If you want to benefit from the new features of this version on WildFly, we also provide WildFly patches for WildFly 10.1 and WildFly 11.0 Alpha1. You can read about how to apply such patches here.

It sounds exciting, how can I help?

First, test it with your applications and report any issues you might encounter.

Then, if you’d like, you can test the new features (the new constraints, the new container element support…​). If you have any issues with the features or the documentation, please report it to us.

Finally, we added a few more built-in constraints in Bean Validation 2.0 and Hibernate Validator 6.0 so we need to update the translations.

English, French, German, Persian, Ukrainian and Brazilian Portuguese are covered but any help on the others are welcome. Just take a look at the translations in our GitHub repository and create a PR (if you’re not aware on how to encode a property file, just push it to us in plain text and we’ll do it).

Getting 6.0.1.Final

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.1.Final. 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).

What about 6.0.0.Final?

6.0.0.Final essentially is the version submitted to the JCP as the Reference Implementation of Bean Validation 2.0. We made quite a lot of improvements on top of it during the Final Approval Ballot period so we decided to release 6.0.1.Final with all these improvements right away.

What’s next?

Well, first, we will get some rest and wait for your feedback on this version.

With your help, we hope to release a new version soon with updated translations.

And finally, we also intent to explore potential features for a future spec revision. Always good to have feedback from the field before setting the API in stone.

Feedback, issues, ideas?

To get in touch, use the usual channels:

Hibernate ORM 5.1.9.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases

We decided to do another release of the 5.1 series to fix some 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.9.Final:

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

We just published Hibernate Search version 5.8.0.Beta4, with AWS integration as well as bugfixes and improvements over 5.8.0.Beta3.

Hibernate Search 5.8.x, just as 5.7.x, is only compatible with Hibernate ORM 5.2.3 and later.

If you need to use Hibernate ORM 5.0.x or 5.1.x, use the older Hibernate Search 5.6.x.

5.8 status

We completed most of the work on new features and improvements for 5.8, and are now mainly working on performance improvements for the Elasticsearch integration.

As a consequence, you can expect the next version we’ll publish to be a candidate release.

Once the CR is out, we will only fix bugs, and functional improvements will have to wait until the next minor release.

So if you plan on using AWS integration, normalizers, analyzer providers, or SPIs for integration of dependency injection frameworks, now’s the last time to ask for improvements before the actual release!

What’s new in Beta4?

AWS integration

Building on the new SPIs introduced in Beta3, we added a new module allowing you to very simply wire your Hibernate Search instance to an AWS-hosted Elasticsearch cluster using Amazon’s proprietary IAM authentication mechanism.

You can find more information about how to use this integration in the reference documentation.

And more!

A summary of other notable changes:

  • HSEARCH-2783: the buffer_size_on_copy configuration property has been deprecated, because we now use Java NIO for file copy and thus don’t need explicit buffering anymore.

  • HSEARCH-2785: using .phrase() and .keyword() on the QueryBuilder for normalized fields no longer fails with Elasticsearch.

  • HSEARCH-2776 and HSEARCH-2777: javax.transaction dependencies are no longer incorrectly marked as optional in the OSGi manifest.

For a full list of changes since 5.8.0.Beta3, please see the release notes.

How to get this release

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.Beta4</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.Beta4</version>
</dependency>

And to also use Amazon’s proprietary IAM authentication mechanism to access your Elasticsearch cluster you’ll also need:

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

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

We just released the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) for the Final Approval Ballot and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR3.

What’s new since CR2

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications and improving a few things here and there.

Here are the highlights of this release:

  • We removed the support for constraints and cascading on container elements of arrays as we decided to not include it in the spec. Basically, it was not possible to be backward compatible with Bean Validation 1.1 and introduce this support, considering how array annotations are handled according to the JLS. As we don’t think there’s much traction for it, we stayed on the safe side for now.

  • It is now possible to use expression language in OSGi environments without having to specify an external class loader: no more headaches trying to get the javax.el based message interpolation working!

  • Speaking of OSGi, Toni Menzel contributed a fix to the Paranamer Karaf feature. Thanks!

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR3

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.CR3. 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).

What’s next?

So, once the Bean Validation 2.0 gets approved, we will release the final of Hibernate Validator 6.0.0.

Until then, we will work on completing the documentation.

Feedback, issues, ideas?

To get in touch, use the usual channels:

We just released a CR2 of the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR2.

What’s new since CR1

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications and on updating the documentation.

Here are the highlights of this small release:

  • The from of @ConvertGroup and <convert-group> is now optional: it defaults to the Default group.

  • Some last minute changes were made in the Bean Validation API on the naming of the value unwrapping related method: we updated Hibernate Validator accordingly.

  • We made a first pass on the documentation: some things are still missing (mostly about the new value extraction feature) but the documentation should not contain outdated information anymore.

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR2

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.CR2. 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?

As we published the Proposed Final Draft, we are in the final stretch for Bean Validation 2.0, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Testing the Reference Implementation is also a good way to help us finalize both the specification and the next major version of Hibernate Validator, now is the time!

The Proposed Final Draft (CR1) of Bean Validation 2.0 has been released earlier this week and it is time to release a version of the Reference Implementation compatible with it: here comes Hibernate Validator 6.0.0.CR1.

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Beta2

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications, fixing bugs and improving overall consistency.

We also added/improved a few things:

  • After a community survey, we decided to create specific annotations for @PositiveOrZero, @NegativeOrZero, @PastOrPresent and @FutureOrPresent instead of using annotation attributes.

  • CDI is now enabled for ValueExtractors loaded via the ServiceLoader. We also fixed a class loading issue in that area.

  • The programmatic API for @NotBlank, @NotEmpty and @Email is now using the new Bean Validation constraints instead of the Hibernate Validator specific ones.

  • We added automatic module names for the new Java 9 module system. You can find them in our reference documentation.

Finally, we made quite a lot of improvements to our testing infrastructure but you shouldn’t notice it (except if you come join us!).

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR1

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.CR1. 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?

As we published the Proposed Final Draft, we are in the final stretch for Bean Validation 2.0, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Testing the Reference Implementation is also a good way to help us finalize both the specification and the next major version of Hibernate Validator, now is the time!

Hibernate ORM 5.1.8.Final released

Posted by    |       |    Tagged as Hibernate ORM Releases

We decided to do another release of the 5.1 series to fix some 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.8.Final:

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

We just published Hibernate Search version 5.8.0.Beta3, with bugfixes and improvements over 5.8.0.Beta2, but also new features such as analyzer providers, normalizers, AWS compatibility and SPIs for integration of dependency injection frameworks!

Hibernate Search 5.8.x, just as 5.7.x, is only compatible with Hibernate ORM 5.2.3 and later.

If you need to use Hibernate ORM 5.0.x or 5.1.x use the older Hibernate Search 5.6.x.

About 5.8

Hibernate Search 5.8 is mainly about:

  • making the Elasticsearch integration compatible with Elasticsearch 5.x (done);

  • improving performance of the Elasticsearch integration (in progress);

  • introducing a new DSL for defining analyzers (done);

  • ensuring that Hibernate Search will work with Java 9 (done, though Java 9 may still change);

  • improving and documenting WildFly Swarm integration (in discussion);

  • removing the need for class definition on master nodes in JMS/JGroups integration (in discussion);

  • and of course, fixing reported bugs.

You can have a look at the roadmap for more details.

What’s new since Beta2?

Programmatic analyzer definitions

You can now define your analyzers programmatically (without annotations), globally (without putting the definition on a particular entity), and in a native way (without using Lucene classes to configure an Elasticsearch analyzer) using analyzer definition providers.

For example, for Lucene your LuceneAnalysisDefinitionProvider might look like this:

public static class CustomAnalyzerProvider implements LuceneAnalysisDefinitionProvider {
    @Override
    public void register(LuceneAnalyzerDefinitionRegistryBuilder builder) {
        builder
                .analyzer( "myAnalyzer" )
                        .tokenizer( StandardTokenizerFactory.class )
                        .charFilter( MappingCharFilterFactory.class )
                                .param( "mapping", "org/hibernate/search/test/analyzer/mapping-chars.properties" )
                        .tokenFilter( ASCIIFoldingFilterFactory.class )
                        .tokenFilter( LowerCaseFilterFactory.class )
                        .tokenFilter( StopFilterFactory.class )
                                .param( "mapping", "org/hibernate/search/test/analyzer/stoplist.properties" )
                                .param( "ignoreCase", "true" );
    }
}

While for Elasticsearch you would have:

public static class CustomAnalyzerProvider implements ElasticsearchAnalysisDefinitionProvider {
    @Override
    public void register(ElasticsearchAnalysisDefinitionRegistryBuilder builder) {
        builder.analyzer( "tweet_analyzer" )
                .withTokenizer( "whitespace" )
                .withCharFilters( "custom_html_strip" )
                .withCharFilters( "p_br_as_space" );

        builder.charFilter( "custom_html_strip" )
                .type( "html_strip" )
                .param( "escaped_tags", "br", "p" );

        builder.charFilter( "p_br_as_space" )
                .type( "pattern_replace" )
                .param( "pattern", "<p/?>|<br/?>" )
                .param( "replacement", " " )
                .param( "tags", "CASE_INSENSITIVE" );
    }
}

As you can see, this allows you to avoid needing to refer to Lucene classes to configure Elasticsearch analyzers.

More details can be found here for Lucene and here for Elasticsearch.

Normalizers for safer sorts

In HSEARCH-2726 and HSEARCH-2659 we introduced normalizers: analyzers that do not perform any kind of tokenization.

We shamelessly borrowed this concept from Elasticsearch, but implemented it in both embedded Lucene mode and Elasticsearch mode. Normalizers are useful for sortable fields: when a field is sortable it should never be tokenized, as this would make the sort order unpredictable; the sort could apply to the first token if you’re lucky, but it could be applied on any other token.

From version 5.8.0.Beta3 onwards, Hibernate Search will log warnings whenever you’re using an analyzer on a sortable field. To resolve this warning change your Analyzer definition to be a Normalizer.

In Lucene, normalizers are just here to help, they work exactly as analyzers. The two differences are that you can’t affect a tokenizer to a normalizer when defining it, and that normalizers have a runtime safety net: should you manage to create multiple tokens, Hibernate Search will concatenate them back to a single token and log a warning.

In Elasticsearch version 5.2 and above, a normalizer will be translated to a native Elasticsearch normalizer, and a text field with a normalizer will take the keyword datatype.

In Elasticsearch version 5.1 and below, native normalizers are not available, thus normalizers are simply translated to analyzers and a text field with a normalizer will take the text (5.x) or string (2.x) datatype.

You can find out more about normalizers in the reference documentation:

AWS compatibility

AWS requires specific, dynamically computed headers in HTTP requests to handle authentication, which until now has made it difficult to use Hibernate Search with an AWS-hosted Elasticsearch.

We introduced a new SPI allowing low-level configuration of the HTTP client, which allows you to plug in the code required to perform the required AWS authentication; this same SPI may be used to integrate with other cloud providers.

We currently have all of our test suite running successfully against an Elasticsearch cluster managed by AWS, with security turned on.

At this stage the SPI is available but we didn’t release the signing component yet; this will be availble in the next milestone: see introduce an AWS module if you want to help!

Dependency injection in FieldBridges

As part of HSEARCH-1316, we’re experimenting with integration with various dependency injection frameworks.

The integration is about allowing you to use annotations such as @Inject, @PostConstruct and so on in your FieldBridges, which may for example allow you to fetch additional data from your application when indexing a given bean.

Integration is currently known to work with Spring DI and CDI. We don’t provide packages for user consumption, but if you are an integrator, or simply if you feel like it, you can have a look at our integration tests:

And more!

A summary of other notable changes:

  • HSEARCH-2606: the discovery_scheme configuration property is now correctly taken into account. Thanks to Matthieu Vincent for reporting and fixing this issue!

  • HSEARCH-2477: shard filtering now works on Elasticsearch.

  • HSEARCH-2603: we now use the Painless scripting language when doing spatial searches on Elasticsearch 5+. Incidentally, this means that it is no longer necessary to perform any server-side configuration on Elasticsearch 5+ to perform any spatial query.

  • HSEARCH-2734: due to a lot of confusion and incorrect (harmful) use, we have deprecated the "ram" name for the RAMDirectory directory provider. If you need it, please ensure you are not using it in a production environment, read about its limitations in the reference documentation, and use its new name: "local-heap".

  • HSEARCH-2735: index-time boosting features (@Boost, @DynamicBoost) have been deprecated with no replacement, and will need to be removed in a future version because Lucene 7 won’t allow index-time boosting anymore. See the reference documentation for alternatives: the suggestion is to switch to using query-time boosting instead.

  • HSEARCH-2665: IndexingInterceptor is no longer considered experimental.

  • HSEARCH-2666: IndexControlMBean is no longer considered experimental.

For a full list of changes since 5.8.0.Beta2, please see the release notes.

How to get this release

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.Beta3</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.Beta3</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

back to top