# Indexation Post treatment

**URL:** <https://discourse.hibernate.org/t/indexation-post-treatment/3753>\
**Category:** Hibernate Search\
**Created:** [February 17, 2020, 2:37pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753 "2020-02-17T14:37:38Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [February 17, 2020, 2:37pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/1 "2020-02-17T14:37:38Z")

</div>

Hello everyone,

```auto
@Entity
@Indexed
public class MyEntity implement IsIndexable {
  private Date updatedAt;
  private Date indexedAt;
}

public interface IsIndexable {
  public Date getUpdatedAt();
  public Date getIndexedAt();
}

```

I would like to update the **indexedAt** field as post-treatment every time my entity is indexed, do you have a generic way to do that ?

What i expect to do :

1. Update my entity with Hibernate (touch updatedAt)
2. Automatic Indexation (thx to hibernate search)
3. Second update after indexation Complete (touch indexedAt)

The idea is to implement an specific interface in my Indexable Entites with two methods, **updatedAt** & **indexedAt** in order to track the entity who are not indexed at a time (maybe with a scheduler) so the rule could be “if indexedAt \< updatedAt then reindex”

Maybe something like HibernateSearch Interceptors ?

do you have any ideas ? Maybe it could be a new feature ?

thx 🙂

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [February 17, 2020, 3:41pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/2 "2020-02-17T15:41:29Z")

</div>

Hello,

Hibernate Search itself treats all entities as read-only, always: it never calls a setter anywhere. So no, there’s no built-in mechanism for this exact solution. I’m not sure I would want to introduce this in Hibernate Search since it could have unexpected ramifications.

That being said, what you’re trying to achieve essentially amounts to building a persisted queue of “reindexing events”, to be processed asynchronously. This is something we’ve wanted to address for a long time ([https://hibernate.atlassian.net/browse/HSEARCH-2364](https://hibernate.atlassian.net/browse/HSEARCH-2364)), and which will probably get solved when we start working on support for clustered applications ([https://hibernate.atlassian.net/browse/HSEARCH-3281](https://hibernate.atlassian.net/browse/HSEARCH-3281)). It will happen for sure, but there are more pressing matters at the moment.

Implementing this on the user side will be challenging, mainly because of `@IndexedEmbedded`: an entity `A` index-embedding entity `B` may need to be reindexed when _`B`_ is modified and `A` is not, so the condition may be much more complex than just “if indexedAt \< updatedAt then reindex”.

On very simple mappings (without `@IndexedEmbedded` and without any complex, custom bridge), I suppose you could implement this in a relatively simple way. You will need to:

1. Make sure `updatedAt` is correctly updated every time the entity is modified; you can take some inspiration from `org.hibernate.search.mapper.orm.event.impl.HibernateSearchEventListener` to do that: it’s a listener to Hibernate ORM change events.
2. Periodically reindex using a `SearchIndexingPlan` as described [here](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#mapper-orm-indexing-manual-indexingplan-process-execute) and [here](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#mapper-orm-indexing-manual-indexingplan-writes), updating “indexedAt” on your entities as you reindex them.

You will, however, need to rely on soft deletes in you database in order to detect deleted entities and delete the corresponding documents from the index.

On more complex mappings (with `@IndexedEmbedded`), you will have to use the same mechanism on _every single entity that can possibly be indexed-embedded_, even those not annotated with `@Indexed`. Then you will process them the same way as above, taking care to call `indexingPlan.addOrUpdate`/`indexingPlan.delete` _even on non-`@Indexed` entities_, at least on those that can possibly be indexed-embedded.

Note that a more efficient approach, if you don’t expect any transient failure when indexing, would be to store “indexedAt” globally instead of per-entity, e,g. in a dedicated utility table. You’ll update it once you’re done reindexing everything. This means you won’t have to write every entity to the database just to reindex them.

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [February 17, 2020, 4:37pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/3 "2020-02-17T16:37:32Z")

</div>

Going through your question a second time, you seem to want to enable automatic indexing.

In that case, I do not understand why you would need to detect all entities that are not indexed; supposedly they will all be indexed at all time?

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [February 17, 2020, 4:42pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/4 "2020-02-17T16:42:00Z")

</div>

In fact, in my case the automatic indexing mecanism could have failure, so i would like a simple way to identifiy entities who are not indexed at a time.

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [February 17, 2020, 5:25pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/5 "2020-02-17T17:25:52Z")

</div>

Ah well, that’s much easier.

There is a thing in Hibernate Search 6 called “AutomaticIndexingSynchronizationStrategy”. You can set your own in a given session by calling `searchSession.setAutomaticIndexingSynchronizationStrategy()`. See [https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html\_single/#mapper-orm-indexing-automatic-synchronization](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#mapper-orm-indexing-automatic-synchronization) for more information.

The interesting bit is that the synchronization strategy is able to set a callback to execute after indexing. That callback will be passed a list of references to all entities that could not be indexed properly.  
Maybe you can take advantage of that?

Here is an example implementation:

```auto
public final class MyAutomaticIndexingSynchronizationStrategy
		implements AutomaticIndexingSynchronizationStrategy {

	private static final Log log = LoggerFactory.make( Log.class, MethodHandles.lookup() );

	public static final MyAutomaticIndexingSynchronizationStrategy INSTANCE = new MyAutomaticIndexingSynchronizationStrategy();

	private MyAutomaticIndexingSynchronizationStrategy() {
	}

	@Override
	public void apply(AutomaticIndexingSynchronizationConfigurationContext context) {
		// Request indexing to force a commit, but not necessarily a refresh.
		context.documentCommitStrategy( DocumentCommitStrategy.FORCE );
		context.documentRefreshStrategy( DocumentRefreshStrategy.NONE );
		context.indexingFutureHandler( future -> {
			// Wait for the result of indexing, so that we're sure changes were committed.
			SearchIndexingPlanExecutionReport report = future.join();
			for ( EntityReference failingEntity : report.getFailingEntities() ) {
				Class<?> entityClass = failingEntity.getType();
				Object entityId = failingEntity.getId();
				// TODO: do something with this class/ID. Add it to a queue somewhere for later reindexing?
			}
		} );
	}
}

```

You can’t set it as the “default” strategy at the moment, but you can set it explicitly on a given entity manager or session this way:

```auto
Search.session( entityManager ).setAutomaticIndexingSynchronizationStrategy( MyAutomaticIndexingSynchronizationStrategy.INSTANCE );

```

Note this must be done _before any entity is modified_, otherwise this won’t have any effect.

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [February 17, 2020, 5:30pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/6 "2020-02-17T17:30:36Z")

</div>

Thank you @yrodiere, i will look into that, it’s seems to be a good way to handle my problem.

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [February 18, 2020, 3:52pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/7 "2020-02-18T15:52:02Z")

</div>

I was working on this part of the code and got another idea: you can also simply use the “queued” synchronization strategy and define a custom [failure handler](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#configuration-background-failure-handling). Since you don’t seem to care that indexing actually happens immediately, this may reduce latency in your application, on top of solving your problem.

Whenever automatic indexing fails for a given entity, the `handle(EntityIndexingFailureContext context)` method will get called. Since you’re using the ORM mapper, you can safely cast the entity references (provided as objects) to `org.hibernate.search.mapper.orm.common.EntityReference`.

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [February 19, 2020, 7:31am UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/8 "2020-02-19T07:31:51Z")

</div>

Yeah that’s a very good idea, i will implement this today with a feedback here, thank you again @yrodiere

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 1:36pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/9 "2020-03-03T13:36:44Z")

</div>

@yrodiere

when i execute the code below with an ElasticSearch cluster offline i got a org.hibernate.search.util.common.SearchException: HSEARCH400588 Error which is great

```auto
SearchSession searchSession = Search.session((EntityManager) sessionFactory.getCurrentSession());
SearchIndexingPlan searchWritePlan = searchSession.indexingPlan();
for (Map.Entry<String, List<Long>> entry : batch.entrySet()) {
			for (Long id : entry.getValue()) {
				searchWritePlan.addOrUpdate(rootRepository.get(getClassByName(entry.getKey()), id));
				logger.info("indexation de l'object {}:{}", entry.getKey(), id);
			}
		}
searchWritePlan.execute();

```

now, if i put on the async mode AND a custom FailureHandler

```auto
hibernateProperties.put("hibernate.search.automatic_indexing.synchronization.strategy", "async");
hibernateProperties.put("hibernate.search.background_failure_handler", "com.xxx.[...].HibernateSearchFailureHandler");

```

Then… i have an empty FailureContext 😭

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/ba0da3bfa8ca8b63e5c6169b750b764ac7c1f0c7.png)

So the sequence seems to be like this in async mode :

- searchSession error is hidden
- spring close the transaction with the httpResponse
- when the transaction close the async FailureHandler is triggered but there is no “dirty” object to index at this moment…

Maybe it’s happening only in my use case because i use two µServices, the first one is not connected to ElasticSearch because it’s too old (Hibernate 3) and i have an Hibernate Interceptors who trigger call to the up-to-date Backend (Hibernate 5) who triggers the final indexation  
Both of the µServices share the same business model.  
In some business case the new backend is just there to read and index.  
In others, it update and trigger the automatic indexation.

here a quick draw to help you understand.

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/065c9ace686b4926871ab66ca074d886583b5602.png)

I would like to share my Failure Handler for both case, automatic and manual updates from my green µServices.

On the other hand, do you know a way to inject a Spring Service into the FailureHandler ?  
I would like to queue my failed entities into a database.

Thank you 😉

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 3, 2020, 1:59pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/10 "2020-03-03T13:59:59Z")

</div>

Okay… there’s a lot to unpack here.

> [@Alexis\_Cucumel](#):
>
> Then… i have an empty FailureContext 😭

This looks like a bug. You shouldn’t end up in this situation unless Hibernate Search failed to queue the indexing works, or failed to describe the failure, … in short, an internal error.

When this happens, what is the exception? Can you call `context.getThrowable().printStackTrace()` and copy the stack trace here?

> [@Alexis\_Cucumel](#):
>
> So the sequence seems to be like this in async mode :
> 
> - searchSession error is hidden
> - spring close the transaction with the httpResponse
> - when the transaction close the async FailureHandler is triggered but there is no “dirty” object to index at this moment…

The description of the failure (the list of entity references) is populated based on the feedback from the backend (which documents failed to be indexed), not based on the “dirty” objects in the Hibernate ORM session. So your use case should work fine regardless.

> [@Alexis\_Cucumel](#):
>
> On the other hand, do you know a way to inject a Spring Service into the FailureHandler ?

Just define your failure handler as a bean, give it a name, and use that bean name in your configuration properties. Hibernate Search should get the bean from Spring, so you’ll be able to use `@Autowired`.

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 3, 2020, 3:51pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/12 "2020-03-03T15:51:42Z")

</div>

Here’s the culprit:

> [@Alexis\_Cucumel](#):
>
> ```auto
> Suppressed: java.lang.NumberFormatException: For input string: "_12443"
> at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Long.parseLong(Long.java:692)
> at java.base/java.lang.Long.parseLong(Long.java:817)
> at org.hibernate.search.mapper.pojo.bridge.builtin.impl.DefaultLongIdentifierBridge.fromDocumentIdentifier(DefaultLongIdentifierBridge.java:23)
> at org.hibernate.search.mapper.pojo.bridge.builtin.impl.DefaultLongIdentifierBridge.fromDocumentIdentifier(DefaultLongIdentifierBridge.java:13)
> 
> ```

Hibernate Search failed to convert the document ID to an entity ID, so it fell back to returning just the exception, without the entity ID.

I’ll change the behavior so that we just skip the document IDs that we cannot convert (and report a failure somewhere else): [[HSEARCH-3851] - Hibernate JIRA](https://hibernate.atlassian.net/browse/HSEARCH-3851)

Regarding the failure to convert the ID, I’m a bit confused… did you insert documents into elasticsearch manually, with IDs that are not longs as they should be? Or maybe you use multi-tenancy and you indexed some documents without a tenant ID?

**EDIT** : Ok, got it. Your tenant ID is the empty string, and there is a bug: [[HSEARCH-3852] - Hibernate JIRA](https://hibernate.atlassian.net/browse/HSEARCH-3852)

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 4:05pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/13 "2020-03-03T16:05:35Z")

</div>

My Hits look like this in ElasticSearch, the underscored ID seems to be technical field.  
The “\_\_HSEARCH\_id” look good

```auto
"hits" : [
      {
        "_index" : "com.xxxx.business.clientphysique",
        "_type" : "_doc",
        "_id" : "_163",
        "_score" : null,
        "_source" : {
          "uuid" : "3585eed9-09b3-496d-ba6a-63f2d6a3055b",
          "acheve" : false,
          "modifieLe" : "2009-09-21T17:56:05.000000000Z",
          "reprise" : true,
          "supprimeLe" : null,
          "searchReferences" : "CLP/ACC",
          "search_reference_sort" : "CLP/ACC",
          "userIds" : [
            2,
            5
          ],
          "civilite" : "MONSIEUR",
          "dateNe" : "1959-07-20T23:00:00.000000000Z",
          "nom" : "xxxxx",
          "nomUsuel" : "xxxxxxx",
          "prenom" : "Gilles, Jacques, Marcel",
          "prenomUsuel" : "Gilles",
          "searchAddress" : "xxxxx",
          "search_address_sort" : "xxxxxx",
          "searchExtendedLabel" : "xxxx",
          "search_extended_label_sort" : "xxx",
          "searchLabel" : "xxxxx",
          "search_label_sort" : "xxxxx",
          "__HSEARCH_id" : "163",
          "__HSEARCH_tenantId" : ""
        },
        "sort" : [
          "xxxxxxxxx",
          "xxxxxx"
        ]
      }

```

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 3, 2020, 4:30pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/15 "2020-03-03T16:30:00Z")

</div>

You don’t need your own references.

Just pass the name of the bean:

```auto
hibernateProperties.put("hibernate.search.background_failure_handler", "myReferenceName");

```

FWIW, there’s a detailed documentation here: [https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html\_single/#configuration-bean](https://docs.jboss.org/hibernate/search/6.0/reference/en-US/html_single/#configuration-bean)

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 4:43pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/16 "2020-03-03T16:43:42Z")

</div>

Yeah, i tried that too 😛  
here what i got before, then i switch to the BeanReference

```auto
Caused by: org.hibernate.search.engine.environment.classpath.spi.ClassLoadingException: HSEARCH000530: Unable to load class [myReferenceName]

```

and if i specify the full qualified name of the class, HSearch Instanciate the class himself

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 3, 2020, 4:48pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/17 "2020-03-03T16:48:28Z")

</div>

This means either the bean wasn’t found by Spring, or the Spring integration in Hibernate ORM is not active.

How do you start Hibernate ORM? Access to Spring from Hibernate ORM (and thus from Hibernate Search) requires specific bits that are included in Spring by default, but if you customized how you start ORM, well…

If you do instantiate Hibernate ORM in a custom way and need a pointer, [here](https://github.com/yrodiere/spring-framework/blob/master/spring-orm/src/main/java/org/springframework/orm/hibernate5/SpringBeanContainer.java) is the class that enables Hibernate ORM to talk to Spring. Not sure where it’s used exactly.

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 4:58pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/18 "2020-03-03T16:58:06Z")

</div>

I use a LocalSessionFactoryBean in a @Configuration annotated class

```auto
    @Bean
    @Primary
    public LocalSessionFactoryBean sessionFactory() {
        LocalSessionFactoryBean sessionFactory = new LocalSessionFactoryBean();
        sessionFactory.setPackagesToScan("xxxxx", "xxxx.business");
        sessionFactory.setHibernateProperties(hibernateProperties());
        sessionFactory.setPhysicalNamingStrategy(new ImprovedNamingStrategy());
        sessionFactory.setAnnotatedPackages("xxxxx.business");
        sessionFactory.setMultiTenantConnectionProvider(multiTenantConnectionProvider());
        CurrentTenantIdentifierResolver currentTenantIdentifierResolver = new CurrentTenantIdentifierResolverImpl(routingService);
        sessionFactory.setCurrentTenantIdentifierResolver(currentTenantIdentifierResolver);
    }

```

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 5:41pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/19 "2020-03-03T17:41:23Z")

</div>

Ok ! I figure out the problem with some breakpoints inside SpringBeanContainer ^^

Here the explanation from my perspective :

when you end up here at the HibernateSearch failure handler creation

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/77bbdb128628ba0764f0a721c2da55e5718df3fe.png)

My bean is correctly referenced inside the beanFactory  
 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/c2165ad4730f152e110fafeeaa83b2e467db9678.png)

But if you evaluate partially the line who get the bean you get the true UnsatisfiedDependencyException:

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/ab9273d90444fae4dfa9cbb472c23279502d1d1d.png)

In fact, at this time the RootRepository i tried to Inject into my FailureHandler wasn’t ready but the Exception was hidden by the fallbackProducer included who seems by default, try to cast the declared string in the background\_failure\_handler configuration into a class

 ![image](https://canada1.discourse-cdn.com/flex035/uploads/hibernate/original/1X/7c8a8f4cc6f26dfb03953664c80286b5cea8eee4.png)

```auto
HSEARCH000529: Unable to find org.hibernate.search.engine.reporting.FailureHandler implementation class: toto

```

My mistake was to not be in debug log level but this kind of Exception is very hidden ^^

Anyway, i solved it by adding **@Lazy**

```auto
@Component("toto")
public class HibernateSearchFailureHandler implements FailureHandler {
	@Autowired
	@Lazy
	private IRootRepository rootRepository;

```

Thanks for the help 😉

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 3, 2020, 5:50pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/20 "2020-03-03T17:50:14Z")

</div>

> [@Alexis\_Cucumel](#):
>
> My mistake was to not be in debug log level but this kind of Exception is very hidden ^^

That’s right… unfortunately we can’t do much about it, given the current integration of Spring/CDI into ORM.

One solution would be to disable the fallback completely, and always delegate to Spring/CDI when it’s available. Not sure that would be practical, though.

Another solution would be to require String references to classes to be formatted differently from String references to beans. For example “classpath:…” vs. “bean:…”. Then we could fail properly in your case, instead of trying to fall back to reflection. But that wouldn’t solve the problem when a class is passed as a property value (are we expected to use reflection, or Spring/CDI)?

---

<div class="post-metadata">

**Author:** ![Alexis\_Cucumel](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/alexis_cucumel/32/687_2.png) [@Alexis\_Cucumel](https://discourse.hibernate.org/u/Alexis_Cucumel)\
**Post date:** [March 3, 2020, 5:55pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/21 "2020-03-03T17:55:39Z")

</div>

> [@yrodiere](#):
>
> Another solution would be to require String references to classes to be formatted differently from String references to beans. For example “classpath:…” vs. “bean:…”. Then we could fail properly in your case, instead of trying to fall back to reflection. But that wouldn’t solve the problem when a class is passed as a property value (are we expected to use reflection, or Spring/CDI)?

I think this could still be better than now 😛 Anyway, i will switch to debug next time 🤣

---

<div class="post-metadata">

**Author:** ![yrodiere](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.hibernate.org/yrodiere/32/1760_2.png) [@yrodiere](https://discourse.hibernate.org/u/yrodiere)\
**Post date:** [March 4, 2020, 3:30pm UTC](https://discourse.hibernate.org/t/indexation-post-treatment/3753/22 "2020-03-04T15:30:57Z")

</div>

@Alexis_Cucumel I just merged a fix for [https://hibernate.atlassian.net/browse/HSEARCH-3851](https://hibernate.atlassian.net/browse/HSEARCH-3851) and [https://hibernate.atlassian.net/browse/HSEARCH-3852](https://hibernate.atlassian.net/browse/HSEARCH-3852), the issues that prevented you from getting the correct list of entities in the failure handler. A new snapshot version including these fixes will be published automatically in about 30 minutes. Please let me know if something is still amiss!

[Next page](https://discourse.hibernate.org/t/indexation-post-treatment/3753.md?page=2)