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.
- DML