[jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1708) Simplify TransportConfiguration parameters
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