NullPointerException when using latest Hibernate Search 6 with @IdClass

Hibernate Search
1

Hi,

I have a not indexed entity (no @Indexed annotation) which actually should be ignored by Hibernate Search. Nevertheless I get a NullPointerException (see the stack trace below) on initialisation. I use Hibernate Search 6.0.0.Beta5. I remember there were issues with supporting @IdClass primary key mappings in previous Hibernate search versions. If it is still the case I would still suppose that this problem does not affect non indexed entities. Is it a bug?

java.lang.NullPointerException at org.hibernate.search.mapper.orm.mapping.impl.HibernateOrmMetatadaContributor.configure(HibernateOrmMetatadaContributor.java:66) at org.hibernate.search.mapper.pojo.mapping.spi.AbstractPojoMappingInitiator.configure(AbstractPojoMappingInitiator.java:91) at org.hibernate.search.mapper.orm.mapping.impl.HibernateOrmMappingInitiator.configure(HibernateOrmMappingInitiator.java:116) at org.hibernate.search.engine.common.impl.SearchIntegrationBuilderImpl$MappingBuildingState.collect(SearchIntegrationBuilderImpl.java:338) at org.hibernate.search.engine.common.impl.SearchIntegrationBuilderImpl.prepareBuild(SearchIntegrationBuilderImpl.java:216) at org.hibernate.search.mapper.orm.bootstrap.impl.HibernateOrmIntegrationBooterImpl.doBootFirstPhase(HibernateOrmIntegrationBooterImpl.java:250) at org.hibernate.search.mapper.orm.bootstrap.impl.HibernateOrmIntegrationBooterImpl.bootNow(HibernateOrmIntegrationBooterImpl.java:194) at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642) at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073) at org.hibernate.search.mapper.orm.bootstrap.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:41) at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:35) at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:386) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1237) at org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:58) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:365) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:391) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:378) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1855) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1792) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:595) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1108) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:868) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550) at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:141) at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:747) at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:397) at org.springframework.boot.SpringApplication.run(SpringApplication.java:315) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1226) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1215)

Best regards,
Sergiy

2

Hi,

It’s definitely a bug that you’re getting an NPE. Even on an @Indexed class, you should get a cleaner error message. I’ll look into that: HSEARCH-3874. Thanks for bringing this to my attention.

Regarding @IdClass, indeed they are not supported for @Indexed entities at the moment. It will be addressed in HSEARCH-1715. I don’t think there’s a workaround at the moment, as you would need to define an IdentifierBridge to convert between your entity ID and the document ID (a string), and currently you need to apply the @DocumentId annotation to a property in order to do that. If you need this right now, I’d suggesting switching from using @IdClass to using @EmbeddedId, at least until we fix HSEARCH-1715.

3

ok. Thank you.
Indeed, the workaround with @EmbeddedId works.

4

@sbarlabanov For your information, the bug was fixed in 6.0.0.Beta6, released today. A non-@Indexed entity type with @IdClass will no longer trigger an exception on startup.

5

perfect. So fast :slight_smile:

Thanks.