Also, it is questionable whether using a properties file should be the default. 
Using the properties file prevents the use of SBM to configure hosts.

Richard, not sure about the reason of using a properties file instead of embedding the properties in the -beans.xml file. Maybe to hide away internal XML details for anyone wanting to make changes to those variables?

I'll check with Manik, but I agree with you that it'd be better to have all properties within the -beans.xml file. If users want to change ports, they shouldn't have to deal with this file and instead use the port SBM. 

Why is a getStringBinding and a getIntBinding property needed? You end up writing the same port twice, wondering how to avoid information duplication...

Any idea Richard?

Galder, i'm not sure I understand your question; as far as I understand it, the call to getStringBinding() returns the hostname for the given service/binding pair in SBM, and the call to getIntBinding() returns the port.

Another q, why do you have to set bind address and port in each of the get binding calls?

Right, so if getStringBinding() returns the host name, why put the port there as well? I mean, this should work, shouldnt it?

                     <value-factory bean="ServiceBindingManager" method="getStringBinding">
                       <parameter>Infinispan</parameter>
                       <parameter>HotRodServer</parameter>
                       <parameter>${jboss.bind.address:127.0.0.1}</parameter>
                     </value-factory>

                     <value-factory bean="ServiceBindingManager" method="getIntBinding">
                       <parameter>Infinispan</parameter>
                       <parameter>HotRodServer</parameter>
                       <parameter>11311</parameter>
                     </value-factory>

Or am I missing something?

Yes, you are :-)
It's a little complicated to explain. I'll work through the examples above:

<value-factory bean="ServiceBindingManager" method="getStringBinding">
<parameter>Infinispan</parameter>
<parameter>HotRodServer</parameter>
<parameter><null/></parameter>
<parameter>${jboss.bind.address}</parameter>
<parameter>11311</parameter><
</value-factory> 

(i) the first two parameters to getStringBinding, namely Infinispan/HotRodServer, serve to identify a ServiceBindingMetadata entry in the SBM configuration - that metadata entry may or may not be present
(ii) the third parameter defines an arbitrary input string, possibly containing embedded strings for ${host}, ${port} and ${hostforurl}. If an input string contains these, they will be substituted for the associated host, port or host (with surrounding square brackets for an IPv6 address - eg string = http://${hostforurl}:${port}/myContext. If the third parameter is null, the hostname is returned.
(iii) the fourth and fifth parameters are used only if the metadata entry does not exist in the SB<M configuration, and a ServiceBindingMetadata entry will be dynamically created using those host and port values.

Same situation for getIntBinding() only there is no input string paranmeter.

So, if you want to take the risk, you could leave off the fourth and fifth parameters of the getStringBinding() call, and the third and fourth patameters of the getIntBinding() and because we have entries in SBM for these service/binding pairs, everything should work OK. But if they are not found for some reason, the server modules may start up with incorrect host and port info.
 

By the way, your question  just caused me to solve a problem I had! This technique of using the third and fourth parameters in getStringBinding() can be used to make use of SBM in test case deployments (when there are no SBM entries for the test deployment in the official SBM configuration). This is something I needed for my fixing of AS 6 for IPv6. Great!

Hmmm, I've tried what I said above but even if you use ports-01, Infinispan servers still listen in 11211 and 11311 respectively, which are the default ports.

We have a problem here: The default ports for memcached and hot rod were defined as 11211 and 11311, so the offset is 100. Now, we'd want to carry on with same defaults, but if you're to switch to ports-01, you'd get 11311 and 11411 which might be risky, since the default hot rod port would now be the alternative memcached one.

The other problem, why ports-01 is not picked is that even if AS passes the new port correctly, the Infinispan server ignores it due to a wrong equality comparison. This happens at least when properties are passed not via properties files.

I've also spotted that even with properties files, SBM might work fine, cos there's a little trick where the the SBM file takes the host/port and assigns it to an internal system property that the properties file seems to use. I do see an advantage of using properties file here cos you could provide more properties that the server might need such as max threads...etc in an easier away, as opposed to fiddling with the beans file. I'm double checking this as well.

For the port thing, we're changing the default port in Infinispan Hot Rod as indicated in https://jira.jboss.org/browse/ISPN-739. 11222 will be the default port for Hot Rod in AS as well.

Now, the reason ports-01 is not being picked is cos when properties are passed via the beans file, the port value comes as an Integer. Now, since we expect Properties to be passed to use, if the value part that a getProperty() should return is anything but a String, null is returned. This is workable although I'm leaning towards properties files for the other properties we can define there, i.e. max threads...etc.

For ports-01 to work fine, I need to implement ISPN-740 and it'll work as expected.

Actually, ISPN-740 is not needed, different port setups work fine even with separate properties file. In fact, due to what I said in my previous comment, this is the only way in which it would work. I'm adding a comment to the properties file to highlight that it works fine with SBM and I'm also adding other properties with default values and information about them.