Hibernate Search 4.5.0.Final is available now.
This minor release could be promoted quickly as we didn't include any new feature compared to the 4.4 series, other than to focus on compatibility with Hibernate ORM 4.3 and WildFly 8 (JPA 2.1 and JavaEE 7 respectively).
The WildFly application server will include this Hibernate Search version, making it even simpler to get started. Our documentation explains how to activate the module, but this will be outdated soon!
Essentially you need to either
- Add a line to the MANIFEST of your deployment
- Declare the dependency in a jboss-deployment-structure.xml file included in your deployment
The documentation still instructs to download the necessary modules, as that's required with WildFly 8.0.0.CR1, but this step should not be necessary in the final version of WildFly 8!
Of course, we'll still provide the same modules in future so that you won't be limited to use the version included in WildFly exclusively, but will always have the option to choose a different version.
Since Hibernate Search is being included in WildFly 8, we're looking forward to it being available to all OpenShift users via the WildFly cartridge.
To remind on all the good reasons to update, these are the most notable improvements of the 4.5 branch:
This Hibernate Search version is meant to work with Hibernate ORM 4.3.x series: our implementation for the JPA 2.1 standard, now included in WildFly 8.
Both Hibernate ORM and Hibernate Search are getting leaner at each release, allowing you to make better usage of your memory.
The MassIndexer is now simpler to tune, and some problems related to lazy initialization exceptions where resolved.
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-orm</artifactId> <version>4.5.0.Final</version> </dependency>
We expect to start rolling out preview tags of Hibernate Search 5 very soon: this is going to be based on the highly requested Apache Lucene 4.
Consequentially the 4.5 branch is from now on in maintenance mode, and will receive only critical fixes or as contributed by goodwilling users.
See our Roadmap for an overview of the plan, and don't hesitate to send suggestions our way!
Latest release from the 4.5 branch is now available:
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-orm</artifactId> <version>4.5.0.CR1</version> </dependency>
Actually we fixed a performance regression: during some of the recent code cleanups we started allocating some objects which seem to be rather expensive; this is resolved now and performance is looking good again [HSEARCH-1486].
If you use Faceting, you might also see some memory allocation improvements [HSEARCH-1468].
The MassIndexer was greatly simplified and as a result it should now be:
- easier to tune (just one threadpool to guess a reasonable size for)
- no more lazy initialization problems on custom FieldBridges: this resolves the highly voted [HSEARCH-1260].
Two tasks which used to be performed by two independent thread pools where unified: if you where tuning your MassIndexer using threadsForSubsequentFetching and threadsToLoadObjects, you should now only use threadsToLoadObjects and probably you want to enlarge this executor a bit more.
See this section of the documentation for an updated explanation of these MassIndexer options.
Tuning property threadsForSubsequentFetching is now deprecated and ignored.
Important reminder: the 4.5 is the stable branch of the series compatible with Hibernate ORM 4.3 and JPA 2.1 and WildFly 8.
If you need to use an older version of Hibernate ORM, you can't benefit from this release: we highly suggest keeping up to date.
I have just released 4.3.1.Final, the first bugfix release for Hibernate ORM 4.3. In addition to bug fixes, a few improvements of note include:
- HHH-5289 : Improved performance of reflection calls
- HHH-6911 : Allows reading and writing @DiscriminatorValue from/to @DiscriminatorColumn when combined with InheritanceType.JOINED (for portability with providers which need DiscriminatorColumn)
- HHH-8865 : Added a new guide on logging to the growing set of topical guides. This is the first know documentation of any sort on using/configuring JBoss Logging, and also discusses some of the more good-to-know specific logging categories. See http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html
See the release page for details of all changes.
Artifacts can be found in the usual places.
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:
- The code location. It is now https://github.com/hibernate/hibernate-orm/tree/master/tooling/metamodel-generator
- The Maven GAV. Even though the group and artifact id stay the same, there is now a version jump from 1.3.0.Final (the last release from the old repository) to 4.3.0.Final (latest stable ORM release):
- The documentation. It is now part of the ORM - see JPA Static Metamodel Generator
- The issue tracker. Please use the Hibernate ORM issue tracker for bug reports and select the metagen component to make it easier for us to categorize bugs
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" );
Validator validator = Validation.byProvider( HibernateValidator.class ) .configure() .addValidatedValueHandler( new PropertyValueUnwrapper() ) .buildValidatorFactory() .getValidator();
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.
Yes, we finally moved the CapeDwarf runtime over to new WildFly codebase! It took time to get all the components aligned, all our provided patches merged and all issues resolved. But it was worth it!
Apart from new runtime with WildFly, we also switched to new Infinispan version 6.x and new UnderTow web server. With new Infinispan version 6.x you get much faster file store impl, while the move to UnderTow allowed us to implement Channel API on top of WebSockets.
The full release notes can be found here:
Download the full .zip distribution:
To name a few new features or resolved issues - we finally have initial OAuth impl, we’re now using original Endpoints resources from GAE for our Endpoints support, Marko found and fixed a nasty namespace bug in our Datastore, and we fixed a bunch of small issues exposed by the GAE TCK.
The old codebase based on JBossAS7 can be found under 1.0 branch in our GitHub repos.
Give this new release a spin. Feedback is welcome as always!
The Hibernate team is proud to announce the Hibernate ORM 4.3.0.Final Release. With this release, Hibernate is now a certified implementation of the JPA 2.1 specification. Certified awesomeness!
A lot of work has gone into this release over the last few months. The main focus of 4.3 was JPA 2.1 support, so much of the work these past few months focused on new JPA 2.1 features. The new features defined for JPA 2.1 include:
- Support for stored procedures. See my previous blog for details
- CriteriaUpdate and CriteriaDelete allow definition and execution of UPDATE and DELETE queries in type-safe Criteria form.
- Entity listeners can now take advantage of dependency injection through CDI.
- AttributeConverters, which define the ability to apply conversions on basic values between their database representation and their representation in your domain model. This is similar in concept to Hibernate's Type contract, although certainly less powerful (can only apply to basic values and operate on in-memory values). On the positive side, JPA AttributeConverters are portable across providers.
- Entity Graph support
- Standardized schema generation. With 2.1 JPA now defines schema generation which is standardized across providers in terms of how generation is performed and the settings providers understand as a baseline. Arun Gupta has a good write up of the basic schema generation support.
- Synchronization of persistence contexts via SynchronizationType
- @ConstructorResult support in result set mappings for native queries
The significant non-JPA work that has gone into 4.3 includes:
- Continued improvement in Hibernate's support for OSGi environments. OSGi support in 4.3 is still somewhat bound by certain design limitations within Hibernate, We plan to fully address these limitations in 5.0 (see HHH-8501 for details).
- Continued work on new bytecode enhancement support within Hibernate, adding support for
inline dirty checking. See HHH-8354 for details.
- Initial break down of the monolithic DocBook-based manuals into smaller Asciidoc-based topical guides (HHH-8606). This is an ongoing process.
While the team is working on master we're keeping an eye on the other two actively maintained branches:
- from stable branch 4.4.x
- to be used with Hibernate ORM 4.2.x (and JPA 2.0, JBoss AS 7.2)
- from development branch 4.5.x
- to be used with Hibernate ORM 4.3.x (and JPA 2.1, WildFly 8)
Both branches where released to address a single bugfix. The problem was in the processing of @IndexedEmbedded relations, specifically in the depth computation in relation with attributes depth and includePaths. Yoann Rodière from OpenWide sent a fix, so we decided to make it immediately available to all users as this could be a blocker for some. For more details see HSEARCH-1442. Thanks Yoann!
This Hibernate Search 4.5.0.Alpha2 release was tested and built against Hibernate ORM 4.3.0.CR2, which is expected to be re-released as the first stable version of Hibernate ORM 4.3. So remember: if you plan to play with the new cool features from the JPA 2.1 spec, you will need to use this version of Hibernate Search (older versions are not compatible with Hibernate ORM 4.3).
We have a new website! It should be super easy to find all the needed links on the new downloads page: hibernate.org/search/downloads/
To celebrate the recent release of Ceylon 1.0, we're putting on a one-day free conference in Paris on Friday, January 24.
The format of the conference is:
- a morning of short presentations about different bits of the Ceylon ecosystem, followed by
- a hands-on Ceylon programming workshop in the afternoon.
Almost the whole Ceylon team will be present, since we're having a four-day team meeting prior to the conference day. So if you have any questions about Ceylon, or if you want to bend our ears on some pet topic, this is your chance.
You can see the conference program, and sign up for the conference here.
P.S. If you're coming to the conference, or even if you're not, please feel very welcome to join the team for drinks on Thursday night.
One of the benefit of rewriting our Hibernate website is that we made our roadmaps more prominent. And in case of Hibernate OGM, we had to write it :)
Hibernate OGM, in a nutshell, is JPA for NoSQL backends (more here).
Gunnar and Davide have made significant forays into the feature set we wanted for our first stable version. This has made writing the roadmap much easier. You can get all the (up to date) details on Hibernate OGM's roadmap page. Here I will sum up what is between us and our first final version.
Option system: offer ability to define per property, per association, per entity or global options. Offered via annotations and via a programmatic API. This system will enable declarative denormalization, specific backend optimization settings and so on.
CouchDB support: offer CRUD support for CouchDB
Performance check: we keep a eye on them but a dedicated round of optimization will happen.
Better navigation with Neo4J: our initial mapping works but we know we can access associations in a faster way.
Batch changes: use the backend batching capability if it exists.
query support for known backends: add our current query support for Neo4J and CouchDB as much as possible.
cache query plans: it's all in the title :) Hibernate ORM already does that, we need to catch up.
I'm sure we will have to chop off a few additional tasks here and there but our goal is to stay focused on these as much as we can.