-
15. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 10:25 AM (in response to timfox)
I don't think there is any need for that - we can just put them in jms-jndi-objects.xml with the jms jndi destinations.
no probsdon't think that's necessary - we can just specify the settings in jms-jndi-objects.xml
I think we've crossed our wires here!
If we can override destination settings in the queues.xml file like you suggested, wouldnt we just have a catch all in there (match="*") instead of defaults in the main configuration. -
16. Re: JBM 2.0 destination config.
timfox Jan 9, 2008 10:29 AM (in response to timfox)Could you rephrase the second part of your question? Maybe I have misunderstood it.
-
17. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 10:35 AM (in response to timfox)ok, so we have queues.xml file which contains entries to override queue settings.
<queue-settings match="*"> <clustered>false</clustered> <full-size>200000</full-size> <page-size>2000</page-size> <down-cache-size>2000</down-cache-size> <dlq>DLQ</dlq> <expiry-queue>ExpiryQueue</expiry-queue> <redelivery-delay>0</redelivery-delay> <max-size>-1</max-size> <max-delivery-attempts>10</max-delivery-attempts> <default-queue-jndi-context>/queue</default-queue-jndi-context> <default-topic-jndi-context>/topic</default-topic-jndi-context> </queue-settings>
so this entry matches all destinations so in essence is the default set of settings. If we do this we dont need to keep them in the jbm-configuration.xml file as we do now! -
18. Re: JBM 2.0 destination config.
timfox Jan 9, 2008 10:43 AM (in response to timfox)"ataylor" wrote:
so this entry matches all destinations so in essence is the default set of settings. If we do this we dont need to keep them in the jbm-configuration.xml file as we do now!
Yes, that was the whole point of having this new configuration file.
All destination settings and security is defined in the file queues.xml.
As you can see this allows all sorts of nice defaulting,
system wide defaults for settings and secuiry.
or stuff like defaults for all temp queues, all topics, all durable subscriptions owned by user X etc.
jbm-configuration just contains server wide settings and doesn't need hot deploy. -
19. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 10:52 AM (in response to timfox)ok, so we're on the same page.
What I plan to do is have some sort of QueueSettingsRepository that can be used to find a property, i.e.queueSettingsRepository.getRedeliveryDelay("queues.testQueue");
This means we can simplify ManagedDestination, removing all these properties. In fact theyre removed they'll be a simple wrapper and we can get rid completely.
Security will be handled the same. -
20. Re: JBM 2.0 destination config.
timfox Jan 9, 2008 11:07 AM (in response to timfox)"ataylor" wrote:
ok, so we're on the same page.
What I plan to do is have some sort of QueueSettingsRepository that can be used to find a property, i.e.queueSettingsRepository.getRedeliveryDelay("queues.testQueue");
This means we can simplify ManagedDestination, removing all these properties. In fact theyre removed they'll be a simple wrapper and we can get rid completely.
Security will be handled the same.
I currently (uncommitted) have a QueueFactory class.
This is used by the postoffice when it needs to create a queuepublic interface QueueFactory { Queue createQueue(long id, String name, Filter filter, boolean clustered, boolean durable, boolean temporary); }
The idea is the QueueFactory implementation applies the correct settings to the queue depending on the config in queues.xml, and return the correctly configured queue.
If you want to take charge of this you could provide the QueueFactory implementation, currently my skeletion version basically doesn't apply any settings -
21. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 11:22 AM (in response to timfox)Were you thinking of applying these settings to the actual queue?
Its just when we redeploy the settings , we would have to go through all the created queues and change them.
I was thinking if holding them separately in and provide a way of checking them. Its really inly ServerxxxEndpoint that uses these properties so instead of saymDest.getMaxSize()
you would usequeueSettingsRepository.getMaxSize(mDest.getName()).
Maybe i should wait until youve checked this code in before i do that, if you leave it as a skeleton i'll implement it. -
22. Re: JBM 2.0 destination config.
timfox Jan 9, 2008 11:27 AM (in response to timfox)I suggest you go on and implement the class - the logic for reading the file, working out the hierarchical settings will be the same however we do it.
This could be done as an isolated unit.
Then if need be just refactor and move things around a little to get it to work with the rest of the stuff. -
23. Re: JBM 2.0 destination config.
ataylor Jan 9, 2008 11:31 AM (in response to timfox)ok sounds good