XML configuration changes

[jmesnil]

I've fixed https://jira.jboss.org/jira/browse/JBMESSAGING-1596 in the trunk.

The intent was to simplify our XML configuration files.
We have a lot of unrelated properties (e.g. address settings, cf settings, etc.) which needed to be in a given order to be valid (e.g. "foo" must be before "bar", etc.)

This would make it very difficult for our users to configure JBM: they'd have to look at the XSD schema to know how to order the XML elements... not very user-friendly (XSD errors are cryptic) and plain ugly!

Now, our configuration files are "bags" of XML elements, they can be in any order.

However, there were a few structure changes to allow that: elements which could appear multiple times must now be inside a container XML element.
For example, all the "connector" definitions must be in a "connectors" elements. The same goes for "acceptor", "broadcast-group", "discovery-group", "bridge", "queue", "divert", "cluster-connection" in jbm-configuration.xml.

Similarly, the "entry" elements of jbm-jms.xml's "connection-factory" must be put inside a "entries" container.

I've updated all the source configuration files we have (src + tests + examples).

[jmesnil]

Doing things in correct order this time: 1st talk about it, then implement it.

XSD forces to have these "containers" element inside a xsd:all when the same element must appear mulitple times.
In order to be consistent, I'll add the same "queues" container to jbm-queues.xml. Wether the queue are defined in jbm-configuration or jbm-queues, the XML will look the same

I'll also change the queue definition to match the style of other elements definition (i.e. elements instead of attributes to define the element characteristics).

Lastly, I've added a "entries" container to the jbm-jms.xml's connection-factory but not for topic or queues.
To be consistent, either I add "entries" container for queue and topic (-1 for that). Or I remove the "entries" container from connection-factory and put all the cf configuration elements in a "configuration" container.

Instead of:

<connection-factory name="MyExampleConnectionFactory">
 <connector-ref connector-name="netty"/>
 <entries>
 <entry name="/MyExampleConnectionFactory"/>
 <entry name="/acme/MyExampleConnectionFactoryDupe"/>
 <entry name="java:/xyz/CF1"/>
 <entry name="java:/connectionfactories/acme/connection_factory"/>
 </entries>
 <ping-period>5000</ping-period>
 <call-timeout>30000</call-timeout>
 <!-- This is the window size in bytes to use when using consumer window based flow control -->
 <consumer-window-size>1048576</consumer-window-size>
 <!-- This is the maximum producer send rate that will be applied when using rate based consumer flow control -->
 <consumer-max-rate>5000</consumer-max-rate>
 <!-- This is the send window size in bytes -->
 <producer-window-size>1048576</producer-window-size>
 <!-- This is the maximum producer send rate that will be applied when using rate based producer flow control -->
 <producer-max-rate>100</producer-max-rate>
 <!-- When using this ConnectionFactory, messages beyond this limit are considered largeMessages and will be sent using smaller packets -->
 <min-large-message-size>10240</min-large-message-size>
 <!-- You can specify the default Client ID to use for connections created using this factory -->
 <client-id>MyClientID</client-id>
 <!-- The batch size in bytes to use when using the DUPS_OK_ACKNOWLEDGE acknowledgement mode -->
 <dups-ok-batch-size>1048576</dups-ok-batch-size>
 <!-- The batch size in bytes to use when using transactional sessions -->
 <transaction-batch-size>1048576</transaction-batch-size>
 <!--Whether or not we use a blocking call when acknowledging a message-->
 <block-on-acknowledge>false</block-on-acknowledge>
 <!--Whether we send non persistent messages synchronously-->
 <send-np-messages-synchronously>true</send-np-messages-synchronously>
 <!--Whether we send persistent messages synchronously-->
 <send-p-messages-synchronously>true</send-p-messages-synchronously>
 <!--If true, any connections will automatically set a unique group id (per producer) on every message sent-->
 <auto-group-id>true</auto-group-id>
 <!--if true then the server will pre ack any message before delivery to a consumer-->
 <pre-acknowledge>false</pre-acknowledge>
</connection-factory>

we will have

<connection-factory name="MyExampleConnectionFactory">
 <configuration>
 <connector-ref connector-name="netty"/>
 <ping-period>5000</ping-period>
 <call-timeout>30000</call-timeout>
 <!-- This is the window size in bytes to use when using consumer window based flow control -->
 <consumer-window-size>1048576</consumer-window-size>
 <!-- This is the maximum producer send rate that will be applied when using rate based consumer flow control -->
 <consumer-max-rate>5000</consumer-max-rate>
 <!-- This is the send window size in bytes -->
 <producer-window-size>1048576</producer-window-size>
 <!-- This is the maximum producer send rate that will be applied when using rate based producer flow control -->
 <producer-max-rate>100</producer-max-rate>
 <!-- When using this ConnectionFactory, messages beyond this limit are considered largeMessages and will be sent using smaller packets -->
 <min-large-message-size>10240</min-large-message-size>
 <!-- You can specify the default Client ID to use for connections created using this factory -->
 <client-id>MyClientID</client-id>
 <!-- The batch size in bytes to use when using the DUPS_OK_ACKNOWLEDGE acknowledgement mode -->
 <dups-ok-batch-size>1048576</dups-ok-batch-size>
 <!-- The batch size in bytes to use when using transactional sessions -->
 <transaction-batch-size>1048576</transaction-batch-size>
 <!--Whether or not we use a blocking call when acknowledging a message-->
 <block-on-acknowledge>false</block-on-acknowledge>
 <!--Whether we send non persistent messages synchronously-->
 <send-np-messages-synchronously>true</send-np-messages-synchronously>
 <!--Whether we send persistent messages synchronously-->
 <send-p-messages-synchronously>true</send-p-messages-synchronously>
 <!--If true, any connections will automatically set a unique group id (per producer) on every message sent-->
 <auto-group-id>true</auto-group-id>
 <!--if true then the server will pre ack any message before delivery to a consumer-->
 <pre-acknowledge>false</pre-acknowledge>
 </configuration>

 <entry name="/MyExampleConnectionFactory"/>
 <entry name="/acme/MyExampleConnectionFactoryDupe"/>
 <entry name="java:/xyz/CF1"/>
 <entry name="java:/connectionfactories/acme/connection_factory"/>
</connection-factory>

wdyt?