Management Console

[ovidiu.feodorov]

Charles,

Here are a few thoughts on possible management console features. Please feel free to add to the thread.

1. A desirable management capability would be to able to assign permissions on a per-destination basis. Currently JBossMQ reads security information from the destination's deployment descriptor. In principle, it needs to know what roles have permissions relative to a destination, and what those permissions are. This XML configuration snippet is self describing:

 <attribute name="SecurityConf">
 <security>
 <role name="guest" read="true" write="true"/>
 <role name="publisher" read="true" write="true" create="false"/>
 <role name="durpublisher" read="true" write="true" create="true"/>
 </security>
 </attribute>

However changing these the security attributes from the console raises the issue of being able to write them back to the deployment descriptor or as an XMBean state, so the next reboot won't loose the changes.


2. The authentication and user-to-role mapping is maintained by a JBoss SecurityManager. JBossMQ only maintains the association to a certain security manager, which is given by a the security manager's JNDI name. JBoss Messaging will use the same system:

<mbean code="org.jboss.mq.security.SecurityManager" name="jboss.mq:service=SecurityManager">
 <attribute name="DefaultSecurityConfig">
 <security>
 <role name="guest" read="true" write="true" create="true"/>
 </security>
 </attribute>
 <attribute name="SecurityDomain">java:/jaas/jbossmq</attribute>
 </mbean>

3. UIL2, HTTPIL and JVMIL sections are irrelevant. JBoss Messaging delegates to JBoss Remoting, which abstracts out the transport layer. The JBoss Messaging peer can be configured to used the same Remoting Connector the Unified invoker uses, or it can start its own. It would be nice to be able to configure the Connector from the GUI, but here we get into functionality that anyone using remoting needs. You should also speak with TomE about this.

4. Queue and Topic browsing would be an interesting feature to have.

5. JBoss Messaging will use a MemoryCache subsystem that is similar with what JBossMQ has now, but I am still working on details. In general, anything that is related to persistence is in a very fluid phase right now. It will solidify in a matter of weeks.

6. The distributed/replicated destinations rely on a JGroups channel (a JGroups channel per JBoss Messaging peer), so it would be nice to be able to configure this from console. Did you bump in JGroups configuration related issues yet?