Inactive Bloggers

While the team is busy on significant internal refactoring, we also accumulated 30 minor fixes and improvements which have been merged in the master branch for Hibernate Search 5.

Since it was a while since the last published tag, today we're publishing this 5.0.0.Alpha5 release to make all these minor improvements available already, while the cooler features will need some more work.

New attribute: includeEmbeddedObjectId

This new attribute of the IndexedEmbedded annotation allows you to control if you want to store all ids for related objects which are embedded in the parent's Lucene Document. Very useful to save space in your index, and so improve performance, when you don't need these identifiers.

Other changes

  • As documented in the Migration guide the API to implement a JMS master node was simplified (but changed!).
  • A possible loss of index update events was fixed, but not a critical issue as this could happen only if you had a significant load and were not using transactions.
  • Better interaction with second level caching.
  • Performance fixes: when the DocumentId doesn't match the JPA id we now still execute an optimal database query.

Full details available in the Release notes.

For more information, please see:

Changes to 4.3.6.Final were mainly bugfixes with some performance improvements. A new Hibernate module was added to provide support for HikariCP connection pool (HHH-8869).

The following bugfixes applied only to 4.3.6.Final:

  • HHH-8818 fixed a regression introduced in 4.3.0.Final causing Hibernate to not be able to find the JNDI DataSource.
  • HHH-4700 fixed a bug using an HQL CASE expression containing a parameter in the THEN clause, and HHH-6747 fixed a bug rendering a SimpleCase using CriteriaBuilder.selectCase( arg ). Both caused ClassCastException to be thrown.
  • HHH-8885 fixed a bug causing a NullPointerException when MapJoin.key() is used.
  • HHH-8980 fixed a bug where an entity was not found if a joined subclass had a non-nullable many-to-one or one-to-one association.

The following bugfixes applied to both 4.3.6.Final and 4.2.15.Final:

  • HHH-9280 - caused the table name computed for an @ElementCollection to use the entity class name instead of the specified entity name.
  • HHH-8310 caused class loading problems due to a Spring bug that changed the context classloader to one that could not locate Hibernate Lob proxy classes (BlobProxy, ClobProxy, NClobProxy, SerializableBlobProxy, SerializableClobProxy).
  • HHH-9106 (for 4.3.6.Final) and HHH-9261 (for 4.2.15.Final) optionally allows multiple representations of the same entity to be merged (e.g., loaded from different sessions).

JBoss Nexus:
Maven Central: (should update in a couple of days)
4.3.6.Final Downloads: 4.3.6.Final ZIP, 4.3.6.Final TGZ
4.2.15.Final Downloads: 4.2.15.Final ZIP, 4.2.15.Final TGZ

It's my pleasure to announce a new release of Hibernate OGM.

Hibernate OGM can now convert JP-QL queries into cypher queries when working with Neo4j. We improved the JSON representation used for associations in CouchDB and MongoDB making it more concise. We also worked on several bug fixes and improvements under the hood, you can read more about it in the release note.

As always, you can either download a release bundle from SourceForge or retrieve the JARs from the JBoss Nexus repository server using Maven, Gradle etc. The GAV coordinates are:

  • org.hibernate.ogm:hibernate-ogm-core:4.1.0.Beta5 for the OGM engine and
  • org.hibernate.ogm:hibernate-ogm-<datastore>:4.1.0.Beta5, depending on the backend you want to use.

From JP-QL to Cypher

For example, if you execute the following JP-QL query:

from Hypothesis h where IN ('alma', 'alfred')

OGM will execute the following Cypher query on Neo4j:

MATCH (h:Hypothesis) WHERE ANY(_x_ IN ["alma", "alfred"] WHERE = _x_) RETURN h

The following subset of JP-QL constructs is available at the moment:

  • simple comparisons
  • the boolean operators AND, OR, NOT

More natural mapping for associations in MongoDB and CouchDB

In the previous releases, an entity with an association looked something like the following JSON:

   "_id": "4f5b48ad",
   "rows": [
           "bankAccounts_id": "7873a2a7"

We got rid of the name of the id in the rows field, this will now look like:

   "_id": "4f5b48ad",
   "rows": [

What's next?

Some work on the Neo4j side is still required to make the mapping of the entities more natural. We also want to add caching in several places to improve performance (OGM-541, OGM-515, OGM-522).

We are also discussing about a solution for the generation of error reports with the failed operations on non-transactional db.

You're very welcome to raise your voice on the mailing list, ask questions in the forum or report any bugs or feature requests in the issue tracker.

If you’re looking for a simple way to secure your Java EE application’s classes and methods, then PicketLink in conjunction with DeltaSpike provides an elegant and flexible solution thanks to DeltaSpike’s support for typesafe security annotations. This powerful combination means you can easily apply security to your application in three simple steps, which we’ll be examining in more detail in this article.

Before we get started though, let’s take a closer look at each of these individual projects.


PicketLink ( is an application security framework for Java EE. It provides features such as Identity Management (IDM), credential management, authentication API, permissions and permission management, plus much more. At the time of writing, the latest available version of PicketLink is 2.6.0.Final.

Apache DeltaSpike

Apache DeltaSpike ( is a collection of portable extensions for Java EE, built on top of the CDI (Contexts and Dependency Injection) standard. It enhances the Java EE platform by providing a set of useful features for application developers. The latest release of Deltaspike is 1.0.

Setting up the Maven Dependencies

This step is required to add the PicketLink libraries to your application. Start by defining a property value for the version of PicketLink that you’ll be using - the latest version at time of writing is 2.6.0.Final. Add the following property declaration to the <properties> section of your project’s pom.xml:

    <!-- PicketLink dependency versions -->

Then add the PicketLink BOM to the <dependencyManagement> section:

      <!-- Dependency Management for PicketLink and Apache Deltaspike. -->

Finally, add the PicketLink dependency to the <dependencies> section:


We’re done! The next step is to enable the DeltaSpike security interceptor.

Enabling the Security Interceptor

For the security interceptor to perform authorization checks for the classes or methods that we wish to secure with our security binding annotations, we must first enable it in our application’s beans.xml file. In a web application this file can be found in the WEB-INF directory. Add the <interceptors> section as shown in the following example:

<beans xmlns=""

Step 1: Create the Security Annotation

This first step is extremely simple - all we need to do is create an annotation and meta-annotate it with @SecurityBindingType. As an example let’s create a security annotation that we can use to restrict access only to users that are currently logged in:

@Retention(value = RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE, ElementType.METHOD })
public @interface LoggedIn { }

Make sure that the @Target is set to both TYPE and METHOD - this will ensure that the annotation can be used to secure either all the methods of a class (when applied to the class itself) or to secure individual methods. The @SecurityBindingType annotation can be found in the package.

Step 2: Create the Authorizer method

This step is where we’ll be implementing the business logic for our security annotation. Each security binding annotation requires a corresponding authorizer method. This method must match the security binding annotation and any of its member values (excluding those annotated with @NonBinding, mirroring the behaviour of CDI itself). There must be exactly one authorizer method per unique security binding annotation usage.

The authorizer method can be placed in a bean class of your choosing, and there are no restrictions on the scope of the bean (in the following example we’ll use an @ApplicationScoped bean). Besides the security binding annotations, the authorizer method must also be annotated with @Secures, to denote that the method is being used to secure that security binding type:

public class Authorizer {
    public boolean isLoggedIn(InvocationContext invocationContext, Identity identity) {
        return identity.isLoggedIn();

The parameters of the authorizer method are treated as injection points (except for parameters of type InvocationContext which may be used to inspect metadata pertaining to the method from which the security check is being invoked). In the above example, we inject the Identity bean which represents the currently authenticated user - the Identity bean provides a method called isLoggedIn() that allows us to check if the current user is logged in.

Step 3: Apply the annotation to your methods

By the time we reach this step all of the hard work has been already done. The only remaining task is to apply the new security binding annotation to the methods and/or classes that you wish to secure. Let’s start off with a really simple example:

public class PostController {
    public void getNewPosts() {
        // business logic here

In this code we’ve applied our @LoggedIn security binding annotation to the getNewPosts() method of a request-scoped bean called PostController. When the user invokes this method, the security interceptor will intercept the method call and invoke the authorizer method to determine if the currently authenticated user is logged in. If the authorizer method returns true then the method invocation will then proceed as normal, otherwise an AuthorizationException will be thrown. If we would like to apply the same security restriction to all of the methods of a bean, we can put the annotation on the bean class instead:

public class PostController {
    public void getNewPosts() {
        // business logic here

A Complete Example

You can find a complete example of using PicketLink with DeltaSpike in the following quickstart project:


In this article we examined how we can get the most out of DeltaSpike’s security annotation feature by combining it with a powerful security framework such as PicketLink. By following three simple steps we learned how to define a new security annotation, implement its business logic and then apply it to the methods and classes which we wish to protect.

26. Jun 2014, 08:19 CET, by Gail Badner

Hibernate ORM 4.2.14.Final was just released! Please see the full changelog for more information:

Another 4.2.x version was necessary to make the following changes:

  • HHH-9255 reverts HHH-9222, which caused incorrect SQL to be generated when bulk deleting collections that use a property-ref;
  • HHH-9252 fixes a bug where an error executing a batch did not abort the rest of the batch.

JBoss Nexus:
Maven Central: (should update in a couple of days)
Downloads: 4.2.14.Final ZIP, 4.2.14.Final TGZ

Showing 1 to 5 of 1212 blog entries