JBoss Releases Hibernate 4.0
- Multi-tenancy support
- The introduction of the "Services" API
- Better logging with i18n support and message codes (via JBoss Logging instead of slf4j)
- Preparation for OSGI support
- Several other cleanups/removal of deprecated code
Multi-tenancy is the ability to virtually partition clients/customers (also called tenants) in a big enterprise application instead of having all data in a shared space. This principle allows for improvements in management, monitoring and even security and is very useful for big service providers. Companies that offer cloud infrastructures can benefit from multi-tenancy as well. There are several ways to implement this principle which include:
- A different database and/or schema for each client/tenant
- The same database/schema for all clients but with an extra column (e.g. tenant_id) in all tables that can be used to filter data
Another important addition is the specification of a "Services" API within Hibernate. This API allows extending Hibernate in several ways beyond the standard built-in services. There were already ways to plugin into Hibernate internals but the Service API offers a formal way to do it from now on. InfoQ contacted Project Lead Steve Ebersole to learn more about the new features:
InfoQ: Can you explain the concept of "Services"? Should they be used for Hibernate extensions only, or might they be useful to application developers as well?
First, I think that it is important to understand that many application developers also develop Hibernate extensions as a routine part of developing those applications. If you develop custom event listeners, custom types, etc you are developing Hibernate extensions. This is not an uncommon scenario.
Think of the Services API as a small, domain-specific CDI for providing unified handling of common behavior and needs such as lifecycle, dependencies, JMX management, etc. So in this regard, yes I can see developers developing Services quite frequently. An easy example of this is an event listener wanting to write to JMS. I can see the JMS aspect as a Service because other listeners or other custom extensions altogether might want to leverage that JMS connection.
But the idea of Services is pretty open ended. Do I see "application code" looking up and directly using Services? No, not generally. But that does not mean everyone will see it that way. Going back to the JMS use case, I can definitely see application code also needing to interact with that JMS connection. So potentially it could look that up from Hibernate. Basically it would be leveraging Hibernate to manage the overall lifecycle.
InfoQ: How important is OSGI for you? How close is Hibernate to full OSGI support?
This is an interesting question. In my experience, when we really start pushing, most people who ask what it means to them for something to have "OSGI support" or be "OSGI compliant", they either do not know or we get very different answers. In my opinion I think it is twofold:
First, can Hibernate work with the modular class loading aspect of OSGI environments? This was definitely tricky before 4.0, as previously Hibernate assumed a pretty conventional ClassLoader setup. In 4.0, one of the standard services is a ClassLoaderService that defines how Hibernate can look up classes and resources as well as how it can resolve standard Java ServiceLoaders. Essentially it defines an API for any and all interaction Hibernate has with the class-path. And more importantly, it defines that, in a swappable manner. The intent here is that non-traditional class loading environments can swap in their own strategy for how Hibernate should interact with ClassLoaders. This is well tested in JBoss AS, which swaps in a custom ClassLoaderService to interact with its modular class loading. So in this respect, Hibernate is already there.
Second, how well does Hibernate define its own "OSGI metadata" in terms of imports/exports? Well today Hibernate does not at all define any OSGI specific metadata in any of its jars. When someone contributes that work we will include it. The thing to keep in mind is that no one on the Hibernate team is an OSGI expert. This is something that someone who is fluent in authoring OSGI metadata and has a vested interest should work on. One step that we have taken on our side in this regard in 4.0 is to split up the packages to better illustrate intended audience, which, if I understand correctly, should make it much easier to author the proper exports.
InfoQ: Why was the logging framework changed?
When Hibernate 4 development started we decided we definitely needed i18n support in the logging. At the time, JBoss Logging was the only logging library with full i18n support including parameterization, to our knowledge. Its i18n support is built more in the vein of GNU gettext, which as a consensus the Hibernate development team preferred over a more Java ResouceBundle approach. JBoss Logging also supports i18n in exception messages through a common approach, though we are not leveraging that functionality.
Additionally, JBoss Logging includes built-in support for message keys as a separate notion from a key into a ResourceBundle for i18n. Rather this is a non-changing key associated with the condition that led to the message being logged. This is a great concept for building FAQs and documentation around those keys. Yes, you could cobble together something similar using SLF4J, Java Util Logging, etc directly. But from a tooling perspective I would argue that it is imperative that these keys be first class citizens. For a large project with lots of such logging you really need to be able to validate that these keys are unique and consistent. So JBoss Logging provides that as well.
InfoQ: Some might argue that the new features are mostly internal. Does that mean that Hibernate has reached a level of maturity where no user-visible changes are added any more? Is Hibernate going into "maintainance" mode?
No, Hibernate is definitely not going into maintenance mode in terms of no new feature development. Does it need maintenance? Sure. Not sure everyone realizes it, but Hibernate is over 10 years old. That is a lot of time for band aids to accumulate. I think we have simply reached a time when we have to stop putting band aids on top of band aids as we plan and develop new features. Hibernate grew out of YAGNI design principles and especially the notion that contracts/APIs will natural become apparent over time. So there is some of that going on as well.
I can think of only a handful of other Java OSS projects that have been around, successful and relevant for that long and all of them have gone through one or more major refactorings.
InfoQ: What can we expect from Hibernate 5? Where is the current development aimed at?
The main focus for 5.0 will be redesigning the model Hibernate uses to stage O/R metadata, both from XML and annotations. This code grew out of Hibernate's initial needs. New requirements from JPA or feature development were simply bolted on. The main reason for this was that many projects use these set of classes and we wanted to minimize disruption for them. But really the time to rethink this model is past due.
The Java artifacts are already in Maven Central so Hibernate 4 is ready for inclusion in Java applications.