Define and verify a clearly limited SPI for Infinispan Query


Infinispan Query is currently needing to access some .impl packages from Hibernate Search; we need to refactor this usage into a clearly defined SPI, so to make sure we will be free to update implementation details in future without breaking Query.

See also:




Hardy Ferentschik
November 10, 2014, 1:06 PM

Hmm, that's quite a log. Some comments:

Not quite sure what the intention is here. DefaultBatchBackend as well as the interface BatchBackend itself are impl classes. If any of this is needed externally we need to move at least the interface into an spi.

That's imo internal. Not sure why that would be needed by Infinispan query.

All these bridges can be replaced with custom bridges with Infinispan Query. I don't think there is a need to expose anything here.

Not sure why the impl is referenced. Anything needed which is not in LuceneOptions?

There is a public metadata API. Would this suffice?

I guess you could do the same things w/o depending on this class

Not sure why there is a direct dependency. What are the details?

That seems just wrong. Infinispan query should not use/reference the Search logger. I would assume it has it's own logger as well?

Gustavo Fernandes
November 10, 2014, 2:56 PM

AFAICT there's some transformation required for the LuceneWorks, so there's a custom visitor impl

Can those be 'promoted' to reusabe bridges along with CalendarBridge, UriBridge, et. al?

Infinispan Query has a modus operandi where schema is defined in a google protobuf message. LuceneOptionsImpl is used to produce Lucene Documents "by hand" without relying on @Indexed, @Field, etc. This is where all happens:

From the javadocs: "Initialization strategies might vary according to the integrating framework; when integrating with Infinispan (as Infinispan Query) no initialization is needed"
I supposed this can be promoted to spi level?

Not sure about this one (how can it be replaced). It is being used inside a custom SearchConfiguration , any thoughts?

There's a custom index manager implementation inside infinispan called org.infinispan.query.indexmanager.InfinispanIndexManager that relies
on DirectoryBasedIndexManager base class but overrides the BackendQueueProcessor and the DirectoryProvider with its own classes

Those can be replaced by infinispan loggers, not sure why they are being used on infinispan side

Sanne Grinovero
November 10, 2014, 5:59 PM

These would require the free-form entity work first.

Needs free-form as well.

Let's promote this to SPI: it's a helper needed by integrators.

Designed for extension by IndexManager implementors; We should promote this to SPI too but we're going to break the SPI right now during

This one is needed, let's promote it to SPI.

Those can be replaced by infinispan loggers, not sure why they are being used on infinispan side


Sanne Grinovero
November 10, 2014, 6:00 PM

I've fixed the usage of loggers. Needed something trivial to do

Gustavo Fernandes
January 12, 2015, 2:46 PM

Infinispan Query is still using

Should this have been promoted to SPI level? Trouble is hibernate search engine osgi bundle does not export this package


Sanne Grinovero


Sanne Grinovero



Suitable for new contributors


Pull Request


Feedback Requested



Fix versions