LuceneBackendQueueProcessor removed in Hibernate Search 5.10. What to use instead

Migrating from Hibernate ORM 4.2.21.Final to 5.3.5.Final. According to the Hibenate site we had to upgrade Hibernate Search as well. Upgraded from 4.4.4 to 5.10.

We have a SwitchingBackendQueueProcessorFactory class - implements BackendQueueProcessor. In it we use the JmsBackendQueueProcessor (we use clusters) and the LuceneBackendQueueProcessor, both implementations of the BackendQueueProcessor interface. Amongst other things both are initialized in our class.

Problem is that the LuceneBackendQueueProcessor implementation is removed in Hibernate ORM 5.x, here 5.10.

Didn’t see a @deprecated notice in the Javadocs of previous version(s) of Hibernate ORM. Can’t find any info about in the 5.x migration guides. Have googled a lot and read the Hibernate forums, all to no avail.

Could you please tell me what has come in place of LuceneBackendQueueProcessor and perhaps even why it has been removed? Any hints/pointers would be very much appreciated.

It has been replaced by:

  • WorkspaceHolder,
  • LocalBackendQueueProcessor.

I don’t know exactly what you’re doing but here is the commit that did it, it might help: .

Thanks, going to have a look at that.

When migrating Hibernate I’ve discovered that things were removed but I couldn’t find info about it, ie Cachekey (removed), CacheImp (removed) and here LuceneBackendQueueProcessor. Perhaps I missed something but I’ve been unable to find info about those removals and the alternatives for it. Are those removals in principle documented or not??

For ORM, we have .

For Search, we have .

Note that sometimes, users extend/implement things that we consider internal and they might not be documented. And there might be some oversights too.

Obviously, migrating from 4.2 to 5.3 is a big step.

Feel free to ask for help with specific patterns if you need it.

The mentioned urls I’ve been using but could not find the info there. Its hard to be complete in release notes I know - been there done that. looks I’ve having a stroke of bad luck.

Thanks for the offer to ask/get additional help.

For Search, the rule of thumb is that you should never have to extend classes that are in .impl. packages. If you have to do so, contact us and present us your use case so that we can either redirect you or think about providing more extension points. We don’t document changes to .impl. packages as we consider noone should extend them: they are purely internal.

For ORM, the situation is a bit less clear: things in .internal. packages should definitely never be extended, but there are some classes that are considered internal and that are not in .internal. packages, mostly for historical reasons.

That should help a lot when migrating.

Again, we are here to help so if you don’t find solution, open a topic with some code explaining what you were trying to do and hopefully we will come up with a solution.