infinispan/infinispan — pull request #2406 by galderz (2014-02-27 17:21:21+00:00)
Title: ISPN-3514 Align XML configuration between Server and Embedded

http://issues.jboss.org/browse/ISPN-3514

For reviewers:
* If tight with time, focus on these XML files: [unified all xml](https://github.com/galderz/infinispan/blob/t_xml/core/src/test/resources/configs/unified/all.xml), [named cache test xml](https://github.com/galderz/infinispan/blob/t_xml/core/src/test/resources/configs/named-cache-test.xml), [sample query and jdbc xml(https://github.com/galderz/infinispan/blob/t_xml/query/src/test/resources/async-store-config.xml), [remote cache store xml](https://github.com/galderz/infinispan/blob/t_xml/persistence/remote/src/test/resources/remote-cl-config.xml), and [level db cache store](https://github.com/galderz/infinispan/blob/t_xml/persistence/leveldb/src/test/resources/config/leveldb-config-java.xml)
* This commits brings in a new way to configure the threading system, where subsystems can share named thread pools. This means that you could define a single thread pool to be used by all, and this is interesting to reduce configuration, and being able to provide better defaults for standalone, maybe with a cached thread pool or fork/join based pool at in the future. The design focuses on three types of thread pools: cached, blocking with configurable parameters and scheduled one. This is similar to the old thread subsystem in AS/Wildfly.
* Finally, @pferraro‎ has to review the XML to make sure AS/Wildfly expectations and embedded ones are inline, and eventually AS/Wildfly/Server should integrate code to ignore those elements that are not relevant for their use case. Any future XML work should be agree with the AS/Wildfly/Server team to keep things aligned.
* As mentioned below, schema/documentation/demos have not yet updated until the XML has been agreed upon.

Commit notes:
* The objective is for server configuration to be readable by embedded and viceversa.
* Those elements that are not relevant for embedded configuration are ignored and highlighted with an INFO message.
* All configuration affecting test results has been adjusted.
* This commit does not include changes to demos, documentation or schema files. This will come later, once the XML has been fully agreed.
* If there's any testing XML that has not been converted, it's because it's not being tested at all, it should be removed in the cleanup phase.
* During the cleanup phase, all unused attributes/elements and parsers will be removed.
* The XML in general follows the pattern used by server which means that there are some noticeable changes to the way embedded XML is configured:
* Cache mode is now part of the cache definition, i.e. local-cache, distributed-cache...etc.
* Default cache is now specified at the cache container level, naming it.
* Shutdown hook now configured as an attribute of cache instead of a separate element.
* X-Site local site derived from transport's site-id, instead of adding yet another xml configuration option.
* Compatibility mode drops enabled attribute, element being present enables it.
* Same thing happens with versioning, element being present enables it.
* Deadlock detection's spin duration used to enable/disable it. If configured with a value below 0, it's disabled.
* unsafe.unreliableReturnValues is now configured via an attribute instead of a separate element.
* store-as-binary is disabled by making sure keys and values are both set to false.
* L1 is disabled by making its lifespan -1.
* Replication queue configured via cache level attributes, and it's disabled by making the queue size negative.

UPDATE (27/02):
* I've bastly simplified the threading programmatic configuration. Programmatically, you can now only plug `ThreadFactory` and `ThreadPoolExecutorFactory` instances, instead of individual elements such as max threads...etc. This makes quite a lot of sense since anyone doing this programmatically can build the right thread factory or thread pool factory, with its own settings, just like AS/Wildfly does. XML wise, you can still configure three types of thread pools, but the details are encapsulated within the the XML parser. I wish we did similar things for other parts of the configuration.http://issues.jboss.org/browse/ISPN-3514

For reviewers:
* If tight with time, focus on these XML files: [unified all xml](https://github.com/galderz/infinispan/blob/t_xml/core/src/test/resources/configs/unified/all.xml), [named cache test xml](https://github.com/galderz/infinispan/blob/t_xml/core/src/test/resources/configs/named-cache-test.xml), [sample query and jdbc xml(https://github.com/galderz/infinispan/blob/t_xml/query/src/test/resources/async-store-config.xml), [remote cache store xml](https://github.com/galderz/infinispan/blob/t_xml/persistence/remote/src/test/resources/remote-cl-config.xml), and [level db cache store](https://github.com/galderz/infinispan/blob/t_xml/persistence/leveldb/src/test/resources/config/leveldb-config-java.xml)
* This commits brings in a new way to configure the threading system, where subsystems can share named thread pools. This means that you could define a single thread pool to be used by all, and this is interesting to reduce configuration, and being able to provide better defaults for standalone, maybe with a cached thread pool or fork/join based pool at in the future. The design focuses on three types of thread pools: cached, blocking with configurable parameters and scheduled one. This is similar to the old thread subsystem in AS/Wildfly.
* Finally, @pferraro‎ has to review the XML to make sure AS/Wildfly expectations and embedded ones are inline, and eventually AS/Wildfly/Server should integrate code to ignore those elements that are not relevant for their use case. Any future XML work should be agree with the AS/Wildfly/Server team to keep things aligned.
* As mentioned below, schema/documentation/demos have not yet updated until the XML has been agreed upon.

Commit notes:
* The objective is for server configuration to be readable by embedded and viceversa.
* Those elements that are not relevant for embedded configuration are ignored and highlighted with an INFO message.
* All configuration affecting test results has been adjusted.
* This commit does not include changes to demos, documentation or schema files. This will come later, once the XML has been fully agreed.
* If there's any testing XML that has not been converted, it's because it's not being tested at all, it should be removed in the cleanup phase.
* During the cleanup phase, all unused attributes/elements and parsers will be removed.
* The XML in general follows the pattern used by server which means that there are some noticeable changes to the way embedded XML is configured:
* Cache mode is now part of the cache definition, i.e. local-cache, distributed-cache...etc.
* Default cache is now specified at the cache container level, naming it.
* Shutdown hook now configured as an attribute of cache instead of a separate element.
* X-Site local site derived from transport's site-id, instead of adding yet another xml configuration option.
* Compatibility mode drops enabled attribute, element being present enables it.
* Same thing happens with versioning, element being present enables it.
* Deadlock detection's spin duration used to enable/disable it. If configured with a value below 0, it's disabled.
* unsafe.unreliableReturnValues is now configured via an attribute instead of a separate element.
* store-as-binary is disabled by making sure keys and values are both set to false.
* L1 is disabled by making its lifespan -1.
* Replication queue configured via cache level attributes, and it's disabled by making the queue size negative.

UPDATE (27/02):
* I've bastly simplified the threading programmatic configuration. Programmatically, you can now only plug `ThreadFactory` and `ThreadPoolExecutorFactory` instances, instead of individual elements such as max threads...etc. This makes quite a lot of sense since anyone doing this programmatically can build the right thread factory or thread pool factory, with its own settings, just like AS/Wildfly does. XML wise, you can still configure three types of thread pools, but the details are encapsulated within the the XML parser. I wish we did similar things for other parts of the configuration.