[jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1708) Simplify TransportConfiguration parameters

[Jeff Mesnil (JIRA)]

Simplify TransportConfiguration parameters
------------------------------------------

                 Key: JBMESSAGING-1708
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1708
             Project: JBoss Messaging
          Issue Type: Task
          Components: Configuration and Management
    Affects Versions: 2.0.0.beta4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


the TransportConfiguration parameters are represented in XML by:

<param key="jbm.remoting.netty.tcpnodelay" value="false" type="Boolean"/>

The user shouldn't have to specify the type attribute as the Acceptor/Connector implementation knows what type they require for a given param key. We can get rid of it.

This would also simplify the Java representation from Map<String, Object> to a more constrained Map<String, String>.
The current code to retrieve a param value can already retrieve a value from a String (as is the case for the JCA resource adapter).

The key values could also be simplified as they are constrained by the acceptor/connector element.
E.g. for INVM configuration, rename "jbm.remoting.invm.serverid" to "id"
for Netty, rename "jbm.remoting.netty.host" to "host", etc.

This would be more intuitive for the user.

With these changes

   <acceptors>
      <acceptor name="netty-acceptor">
         <factory-class>org.jboss.messaging.integration.transports.netty.NettyAcceptorFactory</factory-class>    
         <param key="jbm.remoting.netty.host" value="192.168.0.10" type="String"/>
         <param key="jbm.remoting.netty.tcpnodelay" value="false" type="Boolean"/>
         <param key="jbm.remoting.netty.tcpsendbuffersize" value="1048576" type="Integer"/>
         <param key="jbm.remoting.netty.tcpreceivebuffersize" value="1048576" type="Integer"/>
      </acceptor>
   </acceptors>

would become

   <acceptors>
      <acceptor name="netty-acceptor">
         <factory-class>org.jboss.messaging.integration.transports.netty.NettyAcceptorFactory</factory-class>
         <param key="host" value="192.168.0.10"/>
         <param key="tcpnodelay" value="false"/>
         <param key="tcpsendbuffersize" value="1048576"/>
         <param key="tcpreceivebuffersize" value="1048576"/>
      </acceptor>
   </acceptors>

without any loss of information.

Another possible refinement would be to get rid of the <factory-class> element and replace if by a type attribute on <acceptor>/<connector> which could be either "invm" or "netty" and we can internally have a map between the type values and the class implementation.
<factory-class> is completely generic but I doubt that adding another network framework is a trivial task. It makes the configuration of every user more complex that it could.
If we want genericity, we could still externalize the type<->class mapping in a properties file. This will be modified by power users but remain unchanged for 99% of our users.

With this change, the configuration would looks like:

   <acceptors>
      <acceptor name="netty-acceptor" type="netty">
         <param key="host" value="192.168.0.10"/>
         <param key="tcpnodelay" value="false"/>
         <param key="tcpsendbuffersize" value="1048576"/>
         <param key="tcpreceivebuffersize" value="1048576"/>
      </acceptor>
   </acceptors>

No more implementation detail obfuscates the configuration

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira