Re: [jboss-dev] Bind interfaces coming from ServiceBindingManager

On 04/23/2009 05:37 PM, Brian Stansberry wrote: > I think the binding interface for services that open sockets should be > coming from the ServiceBindingManager, same as the ports do. Currently > most services use ${jboss.bind.address} to inject the address directly > into the consuming service. But that precludes a management tool using > SBM as a central configuration point for all address/port usage in the > server.[1] Currently it's mostly only useful for the ports; if admins > wanted to use something other than ${jboss.bind.address} for a > particular service they'd have to go elsewhere in the tool to > configure that. > > Thoughts? Good idea. On this topic, 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.