From David Lloyd:

"... it might be a Nice Thing to have a custom XML type for service binding configuration, so rather than saying:

<!-- Remote classloading service -->
<bean class="org.jboss.services.binding.ServiceBindingMetadata">
<property name="serviceName">jboss:service=WebService</property>
<property name="port">8083</property>
</bean>

You could say:

<declare-service-binding xmlns="urn:jboss:binding-manager:1.0">
<service name="jboss:service=WebService"/>
<bind address="${jboss.bind.address}" port="8083"/>
</declare-service-binding>

or whatever. And instead of injecting the value with bean tags like this:

<value>
<value-factory bean="ServiceBindingManager" method="getStringBinding">
<parameter>UnifiedInvokerConnector</parameter>
<parameter>${host}</parameter>
</value-factory>
</value>

you could have e.g.

<string-binding-value xmlns="urn:jboss:binding-manager:1.0" service-name="UnifiedInvokerConnector" input="${host}"/>

Then if (and when) the class name/layout of the service binding data changes (and judging from the differences between what's in Branch_5_x and http://www.jboss.org/community/docs/DOC-9038 I'd say we've already had a few such changes), then the same files will continue to work.

Basically, while using xmlns="urn:jboss:bean-deployer:2.0" can be useful for users to assemble their applications and for certain internal applications, we should not be using this as a configuration file format since it exposes implementation details of the underlying services, which then makes it tough for us to change said services.

• DML