JBossDeveloper

This is done. https://jira.jboss.org/jira/browse/JBAS-5822

Only other thing to point out is that using an mbean as the value factory is also supported, but only if the type of any parameters is specifically listed:

<attribute name="Foo">
 <value-factory bean="jboss:service=FooProvider" method="getFoo" default="1100">
 <parameter class="java.lang.String">A</parameter>
 <parameter class="java.lang.Integer">1</parameter>
 </value-factory>
</attribute>

Please see http://wiki.jboss.org/wiki/AS5ServiceBindingManager for a discussion of a reimplementation of SBM based on 1) making it a pojo service that 2) acts as a value-factory. The wiki page is both a design document from which I hope to get input and a first pass at documentation of how the value-factory concepts applies. Any comments appreciated. In particular, for those unwilling to stay awake through my voluminous prose, there are a few points labeled Question: where input would be helpful. :-)

Re: the bootstap: Brian smacks head! Yes, of course. So this is a temporary issue. :-)

A key becomes getting https://jira.jboss.org/jira/browse/JBAS-5349 done so we can safely move stuff out of conf/jboss-service.xml. IMO that one should be marked critical for CR2, even if we don't move anything out of conf/jboss-service.xml for 5.0.0.

A question is what to do with the old org.jboss.system.ServiceBinding interface and it's usage in ServiceConfigurator (and OldServiceConfigurator):

public interface ServiceBinding
{
 /**
 * Possibly override the configuration of a service.
 *
 * @param serviceName the JMX ObjectName of the service
 * @exception Exception thrown on failure to override a configuration
 */
 void applyServiceConfig(ObjectName serviceName) throws Exception;
}

Carlo raised a good point that having all the bindings in a centralized bindings.xml file is clumsy. It should be possible to add basic bindings on the fly. To support this I'm adding two things:

1) ServiceBindingStore has additional methods to allow addition of a binding to all of the named sets it knows about:

 /**
 * Add a ServiceBinding to all binding sets in the store. For each binding
 * set, a new ServiceBinding is added whose serviceName and bindingName
 * properties match the passed binding. The new binding's hostName matches
 * the target set's {@link #getDefaultHostName(String) default host name}.
 * The new binding's port is derived by taking the port from the passed
 * binding and incrementing it by the target set's
 * {@link #getDefaultPortOffset(String) default port offset}.
 *
 * @param serviceName the JMX ObjectName of the service
 * @param serviceConfig the configuration to add
 *
 * @throws DuplicateServiceException thrown if a configuration for the
 * <serverName, serviceName> pair already exists.
 */
 void addServiceBinding(ServiceBinding binding)
 throws DuplicateServiceException;

 /**
 * Remove a service configuration from all binding sets in the store.
 *
 * @param serviceBinding the binding
 */
 void removeServiceBinding(ServiceBinding binding);

 /**
 * Remove a service configuration from all binding sets in the store.
 *
 * @param serviceBinding the binding
 */
 void removeServiceBinding(String serviceName, String bindingName);

 /**
 * Gets the offset from a base value that by default should be added to
 * port values for a given serverName.
 *
 * @param serverName the name of the binding set
 * @return the offset
 */
 int getDefaultPortOffset(String serverName);

 /**
 * Gets the default value to use as the host name for the given serverName.
 *
 * @param serverName the name of the binding set
 * @return the host name
 */
 String getDefaultHostName(String serverName);

 /**
 * Value of <code>InetAddress.getByHost({@link #getDefaultHostName(String) getDefaultHost(serverName)})</code>.
 *
 * @param serverName the name of the binding set
 * @return the host name
 */
 InetAddress getDefaultBindAddress(String serverName);

The concern I expressed on the wiki about using ${host} and ${port} as the syntax to mark values to be replaced by SBM was well-founded. It's easily breakable due to https://jira.jboss.org/jira/browse/JBCOMMON-62, which causes the ${host} or ${port} to be removed from the string if any other property replacement succeeds.

Still, I think the ${host} and ${port} syntax is OK; JBCOMMON-62 needs to be fixed.

"bstansberry@jboss.com" wrote:
A question is what to do with the old org.jboss.system.ServiceBinding interface and it's usage in ServiceConfigurator (and OldServiceConfigurator):

.....

This implementation was just checked in -- like 30 seconds ago ;)

To get the implemenation jar, you'd need to check out the current head of the AS trunk and build it. Once you've done that the jar can be found in build/output/jboss-5.0.0.CR2/server/.../lib/jboss-bindingservice.jar or in varia/output/lib/jboss-bindingservice.jar

I'm curious what you'd do with just the jar though, as opposed to the entire AS that uses it (which the current head now does.)

The current AS trunk has been switched over to this new impl. There are still two services that are not integrated properly with it, so starting two servers using SBM will not work. But it didn't work before either; so now at least people can work off of the new implementation.

The testsuite includes a tests-binding-manager target that starts two instances with the same -b but different binding sets and confirms all services deploy on both. This passes, because I used a couple test-configs to work around the 2 missing services.

The main testing of this is in the varia and system-jmx projects.

Threads discussing the 2 remaining missing services:

1) JBM: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169967#4169967

2) TransactionManager: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=140667

The latter will require a new jbossts release; former is more a coordination issue.

Correct. From a few posts back:

"bstansberry@jboss.com" wrote:

"bstansberry@jboss.com" wrote:
A question is what to do with the old org.jboss.system.ServiceBinding interface and it's usage in ServiceConfigurator (and OldServiceConfigurator):

.....

No comments, so I'm going to get rid of this stuff now.