ClassCastException during creation of index: Hibernate (Search) assumes varchar entity field called "id" is an Integer but it isn't


I run into a ClassCastException(Integer cannot be cast to String) which I found out was related to one varchar field in one of my entities (
For some reason hibernate assumes and treats this field as an integer and later runs into the reported ClassCastException. This only happens if the field is named "id" fully lowercase. Renaming this to "ID" solves the problem.

This all happens while trying to create new Lucene indexes (fullTextEntityManager.createIndexer().startAndWait() for Hibernate Search for my JPA2 entities using Hibernate as JPA2 provider.

How to reproduce:
Load the TestsTable.sql in your MySQL db (see attached zip)
Set up the datasource in JBoss 6.1. (my datasource in excel file)
Deploy a JPA project using the Tests table to the JBoss server (see persistence.xml and
Try creating the indexes through JPA like

private EntityManager em;

public void createSearchIndex(){
try {
System.out.println("Start Lucene Indexing");
FullTextEntityManager fullTextEntityManager = Search.getFullTextEntityManager(em);
System.out.println("Lucene Indexing finished");
} catch (InterruptedException e) {

You will get the ClassCastException:

16:40:46,872 ERROR [] error during batch indexing: : java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at [:3.6.6.Final]
at org.hibernate.type.descriptor.sql.VarcharTypeDescriptor$1.doBind( [:3.6.6.Final]
at org.hibernate.type.descriptor.sql.BasicBinder.bind( [:3.6.6.Final]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet( [:3.6.6.Final]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet( [:3.6.6.Final]
at org.hibernate.loader.Loader.bindPositionalParameters( [:3.6.6.Final]
at org.hibernate.loader.Loader.bindParameterValues( [:3.6.6.Final]
at org.hibernate.loader.Loader.prepareQueryStatement( [:3.6.6.Final]
at org.hibernate.loader.Loader.doQuery( [:3.6.6.Final]
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections( [:3.6.6.Final]
at org.hibernate.loader.Loader.doList( [:3.6.6.Final]
at org.hibernate.loader.Loader.listIgnoreQueryCache( [:3.6.6.Final]
at org.hibernate.loader.Loader.list( [:3.6.6.Final]
at org.hibernate.loader.criteria.CriteriaLoader.list( [:3.6.6.Final]
at org.hibernate.impl.SessionImpl.list( [:3.6.6.Final]
at org.hibernate.impl.CriteriaImpl.list( [:3.6.6.Final]
at [:3.4.1.Final]
at [:3.4.1.Final]
at [:3.4.1.Final]
at [:3.4.1.Final]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_27]
at java.util.concurrent.ThreadPoolExecutor$ Source) [:1.6.0_27]
at Source) [:1.6.0_27]


Windows 7, Java 6.27 (x64), JBoss 6.1 using JPA2, Hibernate 3.6.6.Final, Lucene 3.1.0, MySQL driver 5.1.17, MySQL 5.1.47 (on linux CentOS 5.6 - 2.6.18-238.19.1.el5)


Jan Snelders
September 5, 2011, 4:58 PM

"...(my datasource in excel file)" should have been "...(my datasource is in the attached file)".

Although I filed this bug under Hibernate Search the actual problem might possibly occur just within Hibernate Core. I tried to isolate this as much as possible but I can't get any closer.

Sanne Grinovero
September 5, 2011, 5:01 PM

Hi Jan,
thanks a lot for the test, that's very useful in these cases.

Emmanuel Bernard
September 6, 2011, 10:16 AM

YEs it's very likely a Core issue. We should try and eliminate Search from the equation and see.

Sanne Grinovero
September 6, 2011, 8:15 PM

It was in fact a bug in the MassIndexer. It used the hardcoded property "id" to refer to the identifier; this is valid unless the entity contains a property too which is not the identifier but is nevertheless named id: in this case core will refer to it instead.




Jan Snelders


Suitable for new contributors


Pull Request


Feedback Requested



Fix versions

Affects versions