[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ] Emmanuel Bernard commented on ISPN-4584: ---------------------------------------- Maybe by rethinking how much of these settings the user should see and for how many use cases. Could we impose or default the names of the index data, metadata and locking caches to <owning-cache>_index_data, <owning-cache>_index_metadata, <owning-cache>_index_locking? Could we infer most of their settings, should they all be interlocked (same time out?, some are always REPL, some are always DIST?). Based on that you can infer things and end up with something like {code} <namedCache name="dist_lucene"> <transaction transactionMode="NON_TRANSACTIONAL"/> <clustering mode="DIST"> <hash numOwners="2" /> </clustering> <locking lockAcquisitionTimeout="3000" concurrencyLevel="1000" /> <indexing enabled="true" indexLocalOnly="true"> <properties> <!-- can we infer this, or make it a more compact setting before |properties| maybe an attribute of |indexing storage="infinispan"| <property name="default.indexmanager" value="org.infinispan.query.indexmanager.InfinispanIndexManager" /> <property name="default.exclusive_index_use" value="false" /> <!-- names inferred from the owning named cache, number of owners inferred from the owner's clustering.hash[numOwners], --> <! should we offer the ability to set replTimeout="30000" or can it be inferred? --> <property name="lucene_version" value="LUCENE_36" /> </properties> </indexing> </namedCache> {code} This approach does not replace the old model where all the guts and gory details are exposed. It just makes it much simpler for new comers that don't need to control and fine tune every quark of their body like Dr Manhattan and Sanne. The drawback is that if you need fine tuning, the complexity grows pretty quickly but that's the price of the backward compatibility. Note that most of this trick can probably be implemented in the configuration parser as a front end that spits out what the fully detailed configuration would have been. -- This message was sent by Atlassian JIRA (v6.2.6#6264)