How does this relate to Main's handling of "-b" and the responsibility of Bootstrap to set "jboss.bind.address"? I've been working under the assumption that all system properties currently set by the server must be continued for backwards-compatibility sake. S, ALR 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? > > [1] See my comment on https://jira.jboss.org/jira/browse/JOPR-159 >

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.

Brian Stansberry wrote: > David M. Lloyd wrote: >> 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. >> > > Good idea. https://jira.jboss.org/jira/browse/JBAS-6829 > > Fortunately, the diffs between that design wiki page and the current > stuff happened before 5.0.0.GA. But your point is well taken. > While we're at it. It would also be better if ServiceBindingManager is not part of the VDF bootstrap. I want to get to a point where we can 'hide' the complete VDF bootstrap and do everything in a post-boot Profile Service style. That way the service-binding.xml can theoretically go into deploy. (It'll probable need to go into conf because it must be handled before anything comes up.)

(Hmm, why don't we deploy all these conf files?) Or we could tell the Profile Service to do some 'to be named' directory first.

It would still leave one configuration item on which the Profile Service itself will bind. But even that can be changed afterwards when service-binding.xml is deployed if Profile Service is dynamic enough (or multiple bindings).

Carlo _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development