The org.hibernate.search.bridge.impl.BridgeFactory.getContainerType(XMember, ReflectionManager) method, responsible for determining the container type which will be used among others in org.hibernate.search.bridge.impl.BridgeFactory.getFieldBridgeFromBridgeProvider(BridgeProvider, ExtendedBridgeProviderContext, ContainerType), relies on an @IndexedEmbedded annotation being present on the property.

This means in particular that array/iterable/map field bridges will only be affected to a property if this property carries both a @Field and a @IndexedEmbedded annotation.

*But* when you want to index an array of strings, for instance, putting an @IndexedEmbedded annotation on the property makes no sense, because the purpose of this annotation is to "allow[...] queries involving associated objects properties". Also, the documentation exclusively refers to this annotation in the context of {{@Embeddable}}s or entities, with no word about array bridges.

Furthermore, such practice causes trouble when trying to create an Elasticsearch mapping, as it results in the Elasticsearch property for the embedded and the Elasticsearch property for the Field having the same name.

Maybe we should drop this requirement of having an @IndexedEmbedded annotation for the array/iterable/map bridge to be affected correctly?
This will probably require some changes the the @IndexedEmbedded code, to make sure that the container type will be ignored if the @IndexedEmbedded is absent.
Then (in 6.0?), we may also consider checking for name conflicts between @IndexedEmbedded and @Field