-
30. Re: Configuration storage
jmesnil Mar 25, 2010 1:15 PM (in response to 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
-
31. Re: Configuration storage
ataylor Mar 25, 2010 1:47 PM (in response to clebert.suconic)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?
-
32. Re: Configuration storage
clebert.suconic Mar 25, 2010 1:49 PM (in response to jmesnil)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:
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.
-
33. Re: Configuration storage
clebert.suconic Mar 25, 2010 3:07 PM (in response to 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.
-
34. Re: Configuration storage
clebert.suconic Mar 26, 2010 12:33 AM (in response to 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.
-
35. Re: Configuration storage
clebert.suconic Mar 26, 2010 1:15 AM (in response to 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
-
36. Re: Configuration storage
timfox Mar 26, 2010 5:42 AM (in response to clebert.suconic)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?
-
37. Re: Configuration storage
ataylor Mar 26, 2010 6:09 AM (in response to timfox)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.
-
38. Re: Configuration storage
clebert.suconic Mar 26, 2010 11:33 AM (in response to timfox)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.
-
39. Re: Configuration storage
clebert.suconic Mar 26, 2010 12:33 PM (in response to 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.
-
40. Re: Configuration storage
jmesnil Mar 26, 2010 1:03 PM (in response to clebert.suconic)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
-
41. Re: Configuration storage
timfox Mar 26, 2010 1:14 PM (in response to jmesnil)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!
-
42. Re: Configuration storage
timfox Mar 26, 2010 1:19 PM (in response to 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.
-
43. Re: Configuration storage
clebert.suconic Mar 26, 2010 2:29 PM (in response to timfox)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).
-
44. Re: Configuration storage
jmesnil Mar 27, 2010 9:29 AM (in response to clebert.suconic)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.