Galder,

I am glad we are on the same page. In 5.1.x the changes before specifically only parsed the defaults first then the named cache configurations. This seemed like a better idea for overrides to me at least since then subsequent xml files can override default values.

The reason we need the multiple file overrides is because of how our application is structured. We have a tier structure where each layer is built on top of the last. Each subsequent tier is able to override values from the previous tier if they so desire. The following is the kind of structure you could expect:

1. Server Side Architecture
2. Client Side Architecture
3. Server Integration
4. Shared Application
5. Actual Application
6. Customer Customization

Each of these levels could have their own infinispan xml file. All but the last levels are controlled by development. The customer who installs the software would only ever touch the top most tier, allowing for easier ability to upgrade. The desire is that any setting that they wanted they could possibly override. So if for example we had a default setting to say all caches are LRU with 10000 max entries the top most layer could increase or decrease that number if they had a larger/smaller heap available for usage.

As you mentioned Galder, my main concern is that while using the staxmapper there is really no way to fix this. If I had found a way before I would have proposed a patch.

I may just have to update the company to tell them we cannot use overrides for the default cache and that everyone must use named caches/global configuration values only. This should be acceptable though and would be fine if this is the answer.

The only cache I am actually worried about is the entity named cache since some products have 100's of mapped entities and I know they want to use a default setting for this, but the entity one is a named cache so it works out alright.