Radim Vansa First, thanks for looking.

But, you still keep making this mis-assumption that Region has to map to some concept in Infinispan. It doesn't. So please take a step back here - you'd see that in fact you have almost everything you asked for when hibernate-infinispan is asked to perform these operations...

1. We have talked ad-nauseum about how Region must be able to support multiple kinds of data. That is, a single named region must be able to host a combination of entity, collection and natural-id data. This aspect is not even up for discussion, and we've beaten it to death in prior discussions.
2. Not until a provider is asked to build a RegionAccess is it asked to build something that in any way, shape or form corresponds to any under-lying cache concept - because this is the point where it needs access to the underlying "cache" it will be accessing. You ask that this be "stateless", but then you ask that it hold state ("keeps just references to components" -> state). The provider (you) build the RegionAccess; you can build it however you want.

You'd see that not until you are asked to resolve these to anything Infinispan-specific you have access to:

1. The region name - from Region
2. The AccessType (read-only, transactional, etc) - from the method args
3. Info about the data to be stored there (entity name, mutability of the data, etc) - from the method args

In fact the only bit of information on your "wish list" that you do not currently have access to is "list of entities and/or collections". I could actually give you that when the Region is built as at that point I know all the metadata points where that named region is referenced. The difficulty is what that would look like in terms of passing that info into RegionFactory#buildRegion, specifically to make it "meaningful"? I could simply pass in the Strings (entity-name, collection-role, etc) that will be stored in that region[1]:

interface RegionFactory {
    Region buildRegion(String name, List<String> roleNames);
}

where roleNames are the entity-names, collection-roles, etc to be stored there. The difficulty here is that this does not indicate whether an entry in that List is an entity or a collection or a ... I can see that being useful information.

I could instead pass in a List<NavigableRole>. NavigableRole is new in 6.0; it is just a formalization of this commonality of an entity-name versus a collection-role, etc. That would give you enough info to determine whether each entry is an entity-name or collection-role, etc.

And of course I am open to other suggestions.

In general, I think it is perfectly reasonable for a provider to throw an exception if it encounters a config it does not support.

[1] This is true just for UserModelRegionAccess; for NonUserModelRegionAccess, we do not know this list up front.