We have code responsible for keeping track of the recursion limits when taking ContainedIn into account at runtime:

• org.hibernate.search.engine.spi.ContainedInRecursionContext
• org.hibernate.search.engine.spi.AbstractDocumentBuilder.updateContainedInRecursionContext(Object, ContainedInMetadata, ContainedInRecursionContext)

As it happens, the process of generating metadata requires similar code, but is currently implemented differently with:

• org.hibernate.search.engine.metadata.impl.ParseContext and more specifically its methods isMaxLevelReached(), getMaxLevel(), setMaxLevel(int), getLevel(), incrementLevel() and decrementLevel()
• org.hibernate.search.engine.metadata.impl.PathsContext (which seems to also have an error-tracking purpose in org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.validateAllPathsEncountered(XProperty, PathsContext, IndexedEmbedded))
• org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.checkForIndexedEmbedded(XProperty, Builder, String, boolean, Builder, ConfigContext, PathsContext, ParseContext)
• org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.updatePaths(String, PathsContext, IndexedEmbedded)
• org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.isInPath(String, PathsContext, IndexedEmbedded)

It may be a good idea to factor in these two implementations if they are indeed achieving a similar purpose. Especially since the ContainedInRecursionContext implementation seems simpler.