JBREM-63, configuration pojofication

[starksm64]

My interpretation is that I should just get rid of the code in Connector that parses the "config" element. It looks like JBossXB can unmarshal all of the constructs in the Connector mbean, so, with the right XML schema, we can leave the mbean in its current form. Is that your intention?

Also, there are a couple of problems with ripping the parsing code out of Connector.

1. The Remoting documentation suggests the use of the Connector.setConfiguration() method. E.g.,

// Set xml configuration element.
StringBuffer buf = new StringBuffer();
buf.append("<?xml version=\"1.0\"?>\n");
buf.append("<config>");
buf.append(" <invoker transport=\"socket\">");
buf.append(" <attribute name=\"serverBindAddress\">test.somedomain.com</attribute>");
buf.append(" <attribute name=\"serverBindPort\">8084</attribute>");
buf.append(" <attribute name=\"clientLeasePeriod\">10000</attribute>");
buf.append(" </invoker>");
buf.append(" <handlers>");
buf.append(" <handler subsystem=\"mock\">");
buf.append(" org.jboss.remoting.transport.mock.SampleInvocationHandler");
buf.append(" </handler>");
buf.append(" </handlers>");
buf.append("</config>");
ByteArrayInputStream bais = new ByteArrayInputStream(buf.toString().getBytes());
Document xml = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(bais);
connector.setConfiguration(xml.getDocumentElement());

This comes from a time before Connector accepted configuration maps, and it's no longer necessary, but there could be working code out there that expects the setConfiguration() method.

In my discussion with Tom the Connector object itself seemed superfluous as its just aggregating configuration and parsing. The first step is to ensure that every externalizable behavior has a pojo metadata object. Once that exists, the connector for a given transport should just be configured by specifying its bean descriptor along with its dependencies/properties. The Connector can be kept around for legacy uses, but it should be stripped down to just performing the legacy parsing to produce the new pojo metadata. In general this won't keep up the evolution of the pojos, so it should be deprecated.

2. A number of Remoting unit tests (particularly older ones) use the setConfiguration() method.
What do you think of replacing the current do-it-yourself setConfiguration() method with one that calls JBossXB?

In general use of jbossxb is an improvement, so its a question of porting the testcase descriptors vs producing the pojo metadata using jbossxb parsing. Both should be done. If you look at the mc tests, there is typically a pure programmatic version that only uses the java spis without any descriptors, and a subclass version that produces the same metadata by parsing an external descriptor.

[ron_sigal]

I've made some progress on this issue, so I want to take a minute to describe what I've done.

1. As a first step in the evolution of Remoting configuration, I thougt I would try to minimize the changes, so I've written an XMl schema that describes the current Connector mbean. The only necessary changes are to add a namespace attribute and a serialDataType attribute. So, e.g.,

<server>
 <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket" display-name="TandP">

 <attribute name="Configuration">

 <config>
 <invoker transport="bisocket">
 ...
 <attribute name="timeout" isParam="true">0</attribute>
 ...
 </invoker>
 <handlers>
 <handler>...</handler>
 </handlers>
 </config>
 </attribute>
 </mbean>
</server>

would become

<server>
 <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket" display-name="TandP">

 <!-- CHANGE: added xmlns, serialDataType -->
 <attribute name="Configuration"
 xmlns="http://www.jboss.org/remoting/connector.xsd"
 serialDataType="jbxb">

 <config>
 <invoker transport="bisocket">
 ...
 <attribute name="timeout" isParam="true">0</attribute>
 ...
 </invoker>
 <handlers>
 <handler>...</handler>
 </handlers>
 </config>
 </attribute>
 </mbean>
</server>

2. The schema causes JBossXB to unmarshall the Configuration attribute into an org.jboss.remoting.transport.Configuration object. I've changed the ConnectorMBean.setConfiguration(Element xml) method to ConnectorMBean.setConfiguration(Configuration conf), and left the legacy Connector.setConfiguration(Element xml) method in place, though deprecated. The result is that JBossAS Remoting descriptors will have to be updated, but legacy application code that uses the old version of Connector.setConfiguration() will continue to work.

I also have some questions.

1. Does what I've done conform to what JBREM-63 calls for?

2. I've used a "filename" namespace, "http://www.jboss.org/remoting/connector.xsd", which works for org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver, and I've put the schema in jboss-remoting.jar. Is that OK?

3.

Connector object itself seemed superfluous as its just aggregating configuration and parsing

I suppose the goal is to configure the server invokers as independent pojos, but a problem is that server invokers are created by a factory method in org.jboss.remoting.InvokerRegistry, which is called by Connector. In this particular case, I could change things so that server invokers are created by constructors that register the new invoker with InvokerRegistry, but it seems like a general issue, and I'm wondering if there is a general solution.

-Ron

[starksm64]

1. Does what I've done conform to what JBREM-63 calls for?

No, because the config object is not a bean that encapsulates the configuration metadata for the invoker, at least as far as I can see. The configuration separation is really not expressable as mbeans, but the closest would be something like this:

<server>
 <mbean code="org.jboss.remoting.transport.ConnectorConfig"
 name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket,type=legacyConfig">

 <!-- CHANGE: added xmlns, serialDataType -->
 <attribute name="Configuration"
 xmlns="http://www.jboss.org/remoting/connector.xsd"
 serialDataType="jbxb">

 <config>
 <invoker transport="bisocket">
 ...
 <attribute name="timeout" isParam="true">0</attribute>
 ...
 </invoker>
 <handlers>
 <handler>...</handler>
 </handlers>
 </config>
 </attribute>
 </mbean>

 <mbean code="org.jboss.remoting.transport.Connector"
 name="jboss.remoting:service=TerranceAndPhillip,transport=bisocket">
 <depends optional-attribute-name="ConfigInterface"
 proxy-type="attribute">jboss.remoting:service=TerranceAndPhillip,transport=bisocket,type=legacyConfig</depends>
 </mbean>

</server>

where the org.jboss.remoting.transport.ConnectorConfigMBean would essentially be the interface for the pojo metadata.

What is really needed though is a true invoker pojo that exposes all of the configurable properties so that they can be set as properties on a kernel bean.

<deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd"
 xmlns="urn:jboss:bean-deployer">
 <bean name="Iface0"
 class="...">
 <property name="alias">loopback</property>
 <property name="address">127.0.0.1</property>
 </bean>
 <bean name="Iface1"
 class="...">
 <property name="alias">lan1</property>
 <property name="address">192.168.1.10</property>
 </bean>

 <bean name="BisocketInvoker"
 class="...">
 <property name="addresses">
 <array>
 <value><inject bean="Iface0"/></value>
 <value><inject bean="Iface1"/></value>
 </array>
 </property>
 <property name="handlers">
 <array>
 <value><inject bean="handler0"/></value>
 <value><inject bean="handler1"/></value>
 </array>
 </property>
 </bean>

</deployment>

[starksm64]

2. I've used a "filename" namespace, "http://www.jboss.org/remoting/connector.xsd", which works for org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver, and I've put the schema in jboss-remoting.jar. Is that OK?

should be fine.

[starksm64]

3.
I suppose the goal is to configure the server invokers as independent pojos, but a problem is that server invokers are created by a factory method in org.jboss.remoting.InvokerRegistry, which is called by Connector. In this particular case, I could change things so that server invokers are created by constructors that register the new invoker with InvokerRegistry, but it seems like a general issue, and I'm wondering if there is a general solution.

There are various ways one can register a bean with another bean in the mc without having to code such a dependency. For example, you can use something like this:

 <bean name="BisocketInvoker"
 class="...">
 <install bean="InvokerRegistry" method="addInvoker">
 <parameter>
 <this/>
 </parameter>
 </install>
 ...
 </bean>

this says that the BisocketInvoker bean should be added to the InvokerRegistry bean by calling its addInvoker method with the BisocketInvoker bean instance passed as the argument.