QueueConfiguration currently is requried to take two Configurations.
- One Commons Configuration which is the munged configuration of queues and the queue elements
- One VirtualHostConfiguration to use as the default values.
This makes the QueueConfiguration fragile to changes in our configuration model.
If the QueueConfiguration requres a munged configuration based on the virtualhost configuration then it should retreive the configuration and munged it locally.
This approach of requiring a munged configuration to be provided at construction time. This poses a problem when using plugins that require queue configuration.
If the queue is defined in the virtualhost xml then the VirtualHostConfiguration will create a munged config and provide that to the QueueConfiguration.
If the queue is declared dynamically then only the virtualhost default values will be used. This is fine for alerting which is hard coded but a plugin that needs the queue configuration will not have any configuration to process.
The right thing to do here is to make the QueueConfiguration perform the munging based on how it wants to munge it based on the VirtualHostConfiguration.
Update constructor signature to only take name and VirtualHostConfiguration then perform local munging.
Update tests to correctly create a VHConfig for testing.
Update QueueConfiguration new instance calls to use two parameters.. Only one additional core broker usage in VHC.getQueueConfig... it passes null as the MungedConfig.. hence the problems.
|Field||Original Value||New Value|
|Status||Open [ 1 ]||In Progress [ 3 ]|
|Status||In Progress [ 3 ]||Ready To Review [ 10006 ]|
|Status||Ready To Review [ 10006 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Status||Resolved [ 5 ]||Closed [ 6 ]|