[jmesnil]

please note I was talking about the management controls.

But all this methods will be channeled through the JMSServerManager which needs to have the methods listed by clebert

[ataylor]

Clebert Suconic wrote:

This is what we have agreed today:

We will remove all the drop methods from the Controls.

We should add:

boolean createQueue(String queueName, String jmsSelectorString, boolean durable);

addQueueToJNDI(String queueName, String... jndi); // the jndi will probably be comma separated due to JMX integration

deleteQueueFromJNDI(String queueName, String .. jndi);// the jndi will probably be comma separated due to JMX integration

boolean createTopic(String topicName);

addTopicToJNDI(String topicName, String .. jndi);

Additionally to what we talked, I think we could have two "overloaded methods". So, the user don't need to make separate calls.. he could make the creation

createQueue(String queueName, String jmsSelectorString, boolean durable, String jndi); // the jndi will probably be comma separated due to JMX integration

createTopic(String queueName, String jndi); // the jndi will probably be comma separated due to JMX integration

so no delete methods?

[clebert.suconic]

I would prefer everything through the JMS Control.

I think that's easier (using the had of an user)

For instance, right now I have this class using the JMS Control:

http://anonsvn.jboss.org/repos/jbossas/projects/test/tags/1.1.7.CR1/src/main/java/org/jboss/test/jms/HornetQTestAdmin.java

If we just add a new method, it will mean an easy change.

If you move methods.. it means I will have to add some complexity I don't need now.

[clebert.suconic]

Just confirmed by a quick test that you could actually have commas and spaces on JNDI.

I don't think many users will do it.. but it's definitely allowed.

So, I will change the CFs as well. Will create similar methods on the CFs to addToJNDI.. etc.

[clebert.suconic]

Why createQueue on JMSServerControl only takes the name, and it can take the selector and durability on the JMSServerManager?

I thought the JMSServerControl would just map it for JMX.

[clebert.suconic]

@Andy: I have already changed the JMSManager. I have added addQueueToJNDI, addToicToJNDI... etc.

We need now to change the JMSControllers. I have made a few changes.. but we need to complete those.

Basically, The JMSManager is the central part that controls the JNDI bindings. The Controllers (used by JMX) will call methods on the JMSServerManager. Most of them don't have a reference to the JMSServerManager, but that's an easy to do.

What's left to do now from the JNDI persistence move we agreed today:

- Change the JMS Controllers. (remove the JNDI parameters).

- Adequate the jndi parameters on the CF methods on the JMS Controllers

- Add the method addJNDI to all the Queue, Topic and CF

- Review javadocs on the new methods

From my part yesterday:

- Adequate persistence of CF

- Replicate the new JMS Journal

- Tests

[timfox]

Can someone, (andy/clebert), explain to me why we need all this JMS management stuff duplicated in two places:

1) JMSServerManager

2) JMSServerControl

What's the relationship between the two?

[ataylor]

Tim Fox wrote:

Can someone, (andy/clebert), explain to me why we need all this JMS management stuff duplicated in two places:

1) JMSServerManager

2) JMSServerControl

What's the relationship between the two?

JMSServerControl uses simple parameters so it is what is exposed via JMX, used by admin console etc. for instance instead of taking A String[] it would take a comma delimited string. This then decodes the strings and delegates to the actual implementation JMSServerManager, which is what would take care of creating the queues, persistence etc. This is the same for HornetQServerControl and the other controlclasses.

[clebert.suconic]

Tim Fox wrote:

Can someone, (andy/clebert), explain to me why we need all this JMS management stuff duplicated in two places:

1) JMSServerManager

2) JMSServerControl

What's the relationship between the two?

JMSServerControl is the JMX exposal

JMSServerManager is what controls the JMS cases (JNDI.. etc).

It's the same analogy as we have the HornetQServer/HornetQServerImpl versus HornetQServerControl/HornetQServerControlImpl.

[clebert.suconic]

When the user will want a JMS Queue with expressions? I can understand it on Consumers or Topic Subscriptions.. but on  JMS Queues?

I did a quick inspection of the code and I dont see JMSServerManager.createQueue exposed with an expression anywhere.

[jmesnil]

Clebert Suconic wrote:

When the user will want a JMS Queue with expressions? I can understand it on Consumers or Topic Subscriptions.. but on  JMS Queues?

I did a quick inspection of the code and I dont see JMSServerManager.createQueue exposed with an expression anywhere.

Users can specify a selector for queues in hornetq-jms.xml.

For consistency, we should also allow them to specify a selector from our management API

[timfox]

Jeff Mesnil wrote:

Clebert Suconic wrote:

When the user will want a JMS Queue with expressions? I can understand it on Consumers or Topic Subscriptions.. but on  JMS Queues?

I did a quick inspection of the code and I dont see JMSServerManager.createQueue exposed with an expression anywhere.

Users can specify a selector for queues in hornetq-jms.xml.

For consistency, we should also allow them to specify a selector from our management API

+1

Clebert - BTW this is in the user manual. RTFM!

[timfox]

http://hornetq.sourceforge.net/docs/hornetq-2.0.0.GA/user-manual/en/html/queue-attributes.html

Predefined queues with selectors is a value add feature of HornetQ.

Anything that can be deployed via xml should also be deployable via the management api.

[clebert.suconic]

ok, I just got confused because that wasn't available through the Controller. I had added a JIRA to update the controller.

So.. as we talked today, I will finish the replication on the JMS journal.

To the CF persistence, I have added persistence support on the method createConnectionFactory(final ConnectionFactoryConfiguration cfConfig).

However, there are other methods that are also creating CFs. (taking the classNames.. etc).

One way to fix this easily would be to have all the other methods delegating to the createConnectionFActory(Config) method. But for that we would need to add support to persist the TransportConfiguration. (Right now it's persisting only the connectorNames).

[jmesnil]

Clebert Suconic wrote:

One way to fix this easily would be to have all the other methods delegating to the createConnectionFActory(Config) method. But for that we would need to add support to persist the TransportConfiguration. (Right now it's persisting only the connectorNames).

I've added persistence of the TransportConfigurations used by the ConnectionFactoryConfigurationImpl.