-
15. Re: Configuration storage
timfox Mar 23, 2010 7:35 AM (in response to ataylor)Andy Taylor wrote:
This was discussed at the F2F and agreed on by every one, when the user creates a new destination they should be able to configure settings and security at the point the queue is created. Exactly like the screen shot shows.
Yes, sure. But they still go in core, not jms server.
>> Persistence ill take priority over xml config.
Are they additive?
>> fyi, the admin console will only have JMS objects for this version.
Not sure what you mean by that. Can you elaborate?
-
16. Re: Configuration storage
ataylor Mar 23, 2010 7:39 AM (in response to timfox)I'm not sure what you mean by "they go in core"
what do you mean by additive.
I mean the admin console will have the ability to configure JMS Resources only, i.e. queues, topics and connection factories. Basically we decided to concentrate on what we need from an AS pov.
-
17. Re: Configuration storage
leosbitto Mar 23, 2010 7:49 AM (in response to ataylor)I think that it would be nice if it would be possible to recreate the xml config from the persistence, for those users who would like to be able to migrate parts of their configuration (e.g. some queues with their settings) from one HornetQ server to another. I am thinking about configuring the test/devel server and then providing the final tested configuration to the production server.
-
18. Re: Configuration storage
ataylor Mar 23, 2010 7:54 AM (in response to leosbitto)Leos Bitto wrote:
I think that it would be nice if it would be possible to recreate the xml config from the persistence, for those users who would like to be able to migrate parts of their configuration (e.g. some queues with their settings) from one HornetQ server to another. I am thinking about configuring the test/devel server and then providing the final tested configuration to the production server.
That wouldnt be practical as there cold be hundreds of thousands of queues.
-
19. Re: Configuration storage
timfox Mar 23, 2010 8:02 AM (in response to ataylor)Andy Taylor wrote:
I'm not sure what you mean by "they go in core"
what do you mean by additive.
I mean the admin console will have the ability to configure JMS Resources only, i.e. queues, topics and connection factories. Basically we decided to concentrate on what we need from an AS pov.
addressettings and security settings are core things, so if they need to be persisted that should occur in core, not the jms layer.
additive means, can we deploy some stuff from xml *and* other stuff from storage?
what happened to all the work you did with the non JMS queues and topics management?
-
20. Re: Configuration storage
leosbitto Mar 23, 2010 8:05 AM (in response to ataylor)Andy Taylor wrote:
Leos Bitto wrote:
I think that it would be nice if it would be possible to recreate the xml config from the persistence, for those users who would like to be able to migrate parts of their configuration (e.g. some queues with their settings) from one HornetQ server to another. I am thinking about configuring the test/devel server and then providing the final tested configuration to the production server.
That wouldnt be practical as there cold be hundreds of thousands of queues.
So what? I don't care if the XML document gets big. I prefer having something readable and versionable (e.g. the XML document) to some binary configuration blob (which is what your persistence seems to be - please correct me if I am wrong).
-
21. Re: Configuration storage
ataylor Mar 23, 2010 8:18 AM (in response to timfox)Tim Fox wrote:
Andy Taylor wrote:
I'm not sure what you mean by "they go in core"
what do you mean by additive.
I mean the admin console will have the ability to configure JMS Resources only, i.e. queues, topics and connection factories. Basically we decided to concentrate on what we need from an AS pov.
addressettings and security settings are core things, so if they need to be persisted that should occur in core, not the jms layer.
additive means, can we deploy some stuff from xml *and* other stuff from storage?
what happened to all the work you did with the non JMS queues and topics management?
Ok, we can persist address settings etc in core.
yes, they will be additive then.
That stuff cant be used if we are using the profile service now not JMX but we could still use this for the standalone admin tool when we implement it.
-
22. Re: Configuration storage
ataylor Mar 23, 2010 8:21 AM (in response to leosbitto)Leos Bitto wrote:
Andy Taylor wrote:
Leos Bitto wrote:
I think that it would be nice if it would be possible to recreate the xml config from the persistence, for those users who would like to be able to migrate parts of their configuration (e.g. some queues with their settings) from one HornetQ server to another. I am thinking about configuring the test/devel server and then providing the final tested configuration to the production server.
That wouldnt be practical as there cold be hundreds of thousands of queues.
So what? I don't care if the XML document gets big. I prefer having something readable and versionable (e.g. the XML document) to some binary configuration blob (which is what your persistence seems to be - please correct me if I am wrong).
Ok, fair enough but this won't happen for this version and its not really a requirement for HornetQ.
-
23. Re: Configuration storage
clebert.suconic Mar 23, 2010 9:31 AM (in response to timfox)Tim Fox wrote:
Clebert Suconic wrote:
If you look at the attachments on Andy's message:
http://community.jboss.org/message/532433#532433
He's managing address settings & security settings.
I could just do it alltogether around Queue names, but I don't think that's the proper way of doing it.
I know for instance we need to persist Connection Factories. If I provide a generic way now, it could be easily reused later, while the development time would be the same here.
I expected it to be done by the end of yesterday. This should be a two hour copy and paste job. Maybe quicker for you since you are familiar with the journal.
Looks like all we got after one day is an email outlining how to do this
I'm already implementing it.. and I was expecting to finish today / tomorrow.
"Two hours job" is the famous last words for this project.
I'm still on the same development track I was yesterday. If you guys disagree on anything, please speak *now*.
-
24. Re: Configuration storage
clebert.suconic Mar 25, 2010 2:05 AM (in response to clebert.suconic)I have uploaded my changes into https://svn.jboss.org/repos/hornetq/branches/Clebert_TMP
I wanted to test it a little bit more before I could put it on trunk.
The code is already saving and restoring AddressSettings, SecurityRoles and partially ConnectionFactories
ConnectionFactories are created in several ways and are not always going through ConnectionFactoryConfiguration object. I'm looking into a way to standardize the methos through ConnectionFactoryConfiguration what should make it easier. I will do it tomorrow.
I should also do some work on the Replication for the new journal, but that shouldn't be a big deal.
-
25. Re: Configuration storage
clebert.suconic Mar 25, 2010 2:07 AM (in response to clebert.suconic)In regard to the CF configs... I was talking about JMSServerManagerImpl:
on my branch, createConnectionFactory(final ConnectionFactoryConfiguration cfConfig) is storing the CF.
But the other methods are instantiating the Transports directly and not instantiating the CF. Those methods should also be changed to created a CFConfig and call the storeConnectionFactory.
-
26. Re: Configuration storage
ataylor Mar 25, 2010 10:53 AM (in response to clebert.suconic)Ive done topics and queues, will check in soon!
-
27. Re: Configuration storage
clebert.suconic Mar 25, 2010 11:36 AM (in response to ataylor)There's one thing I don't understand on the JMSManager api.The createQueue signature is:createQueue(final String queueName,final String jndiBinding,final String selectorString,final boolean durable)So, it is possible the user doing something like:createQueue("MyQueue", "/queue/firstbinding", null, true);createQueue("MyQueue", "/queue/mySecondBinding", "expression by mistake", false);However this wouldn't make any sense. Since the core queue was already created with the first expression, and with the first durable parameter.This works well for topic. Multiple calls to createTopic will just mean adding another JNDI Binding.I believe we would need something likecreateQueue(String queueName, String[] jndiBindings, String selectorString, boolean durable);and then:addBindingToQueue(String queueName, String binding);deleteBindingFromQueue(String queueName, String binding);or maybe just deleteBinding(String binding);thoughts? -
28. Re: Configuration storage
clebert.suconic Mar 25, 2010 1:02 PM (in response to clebert.suconic)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
-
29. Re: Configuration storage
jmesnil Mar 25, 2010 1:09 PM (in response to clebert.suconic)my2c, I'd move the methods to add JNDI bindings to the DestinationControl interface (this is more consistent since this is where the JNDI bindings are also displayed).
To sum up:
JMSServerControl
boolean createQueue(String queueName, String jmsSelectorString, boolean durable);
boolean createQueue(String queueName, String jmsSelectorString, boolean durable, String... csvJNDI);
boolean createTopic(String topicName);
boolean createTopic(String topicName, String csvJNDI);
DestinationControl
String[] getBindings();
boolean addJNDIBinding(String jndi);
boolean removeJNDIBinding(String jndi);
wdyt?