[ataylor]

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 probs

don'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.

[timfox]

Could you rephrase the second part of your question? Maybe I have misunderstood it.

[ataylor]

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!

[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.

[ataylor]

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.

[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 queue

public 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

[ataylor]

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 say

mDest.getMaxSize()

you would use

queueSettingsRepository.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.

[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.

[ataylor]

ok sounds good