Configuration storage| JBoss.org Content Archive (Read Only)

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 like

createQueue(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?