The ElasticSearchBridgeProvider implementation essentially overrides the indexing format of some types, but this means that merely having the implementation on the classpath will affect the format of other indexes.
On top of that, we should also still allow running some indexes on ES and some other indexes using the plain Lucene integration.
So... I took a look at this. Mainly by trying to reorganize the SearchIntegratorBuilder.initDocumentBuilders to have the IndexManagers information earlier and exploit them in the fieldBridge metadata construction.
While extracting the IndexManager configuration and exploiting it at initialization seems doable for root entities, doing so for contained entities is not feasible as they can potentially be contained in 2 entities which might be using 2 different IndexManagers. And we won't know it except at runtime.
Did I miss something?
The solution would be to have a separate instance of org.hibernate.search.engine.spi.DocumentBuilderContainedEntity for each root point. For example if "Author" is embedded in both entities A and B, you'd have a different builder instance for A.author and B.author; at this point each instance of DocumentBuilderContainedEntity could be flagged as "belongs to indexmanager X" and hold the information you need.
See also commit id 332f702 : when fixing this, we need to re-enable the MassIndexingTimeoutIT integration test.