In releases of JBoss Data Grid earlier than 7.2, the configuration for network partition handling was as follows:

<partition-handling enabled="true|false">

As of JBoss Data Grid 7.2 the following configuration takes effect:

<partition-handling when-split="ALLOW_READ_WRITES" merge-policy="NONE"/>

Before migrating to JBoss Data Grid 7.2, you should review the documentation to understand the different partition handling strategies and merge policies that JBoss Data Grid can use to resolve conflicts.

See the following sections of the Administration and Configuration Guide for more information:

JBoss Data Grid 7.2 improves the data container by deprecating the eviction configuration and adding a memory configuration. You should review these changes before migrating from an earlier release. For more information, see Set Up JVM Memory Management in the Administration and Configuration Guide.

The underlying Hibernate Search modules have been upgraded from 4.6 to 5.6, and as such there have been significant changes to this component. The following sections walk through all updates necessary to use the new version.

Several classes have been relocated to a different package than their previous package; the following table includes the original class name and package along with the new location.

The following additions have been made to the Hibernate Search modules:

Any id fields are an exception to this rule. Even when these fields are represented by a numeric type they will continue to be indexed as a string keyword by default.

The changes mean the use of @NumericField is now obsolete, unless a custom precision for the numeric encoding is explicitly specified.

Previous, string based, index format may be used by specifying a string encoding field bridge. For integers this is org.hibernate.search.bridge.builtin.IntegerBridge; other publicly available field bridges may be found in the org.hibernate.search.bridge.builtin package.

For dates and calendars the indexing format may be changed via the EncodingType enum; for example, @DateBridge(encoding=EncodingType.STRING) or @CalendarBridge(encoding=EncodingType.STRING).

@IndexedEmbedded(includeEmbeddedObjectId=true)

// Previous API call
fulltextQuery.setSort( new Sort( new SortField( "title", SortField.STRING ) ) );

// New API call
fulltextQuery.setSort( new Sort( new SortField( "title", SortField.Type.STRING ) ) );

Any applications not precisely matching the Lucene field encoding for sorting options in Lucene 4 would have worked without error; however, the new version of Lucene 5 now correctly catches these errors and will report a runtime exception. The expected field encoding must be matched according to its type. A field indexed as a String requires a single term, even after analysis, a numeric field encoded as an Integer must match SortField.Type.INT, a numeric field encoded as a Long must be sorted with SortField.Type.LONG, and so forth.

Similarly, many of the Solr utility classes, such as TokenizerFactory or TokenFilterFactory were moved into Apache Lucene. Any applications using these classes should also be updated using the Lucene’s API documentation.

Due to this refactoring the Solr dependencies are now incorporated within Lucene, and no longer need to be specified; any applications that previously had Solr dependencies defined should remove them and only use the Lucene dependencies.

The following list are deprecated classes within the Hibernate Search modules: