> If disabling the queue and exchange declares is > an option for you (i.e you can rely on them being present already) then > you > should be able to use that change along with the system properties I > mentioned to do so. If not, we can try to work out a suitable course to > allow manipulating the exchange declare properties.
We are running a mixed bag here. Some queues are predefined, while others (actually system named topics) are temporary and defined on the fly. Consequently, the proposed solution doesn't address all our use cases. I find it odd that qpid.declare_exchanges is a global parameter as it implies an all-or-none configuration approach. Most, if not all, my experience in messaging systems have always leveraged on-the-fly queue/topic creation. Would it not be worthwhile having a plane property object with these properties that can be passed to the method? Defaults values, possibly based on system env values, could be set on object creation and reset. Additional methods without the property object could also be provided where system defaults are assumed. Concerning your comments on the 'noWait' issue. I was concerned that while my changes did solve my 0-9-1 issues, it might create regression issues and break the same use case running against a broker operating a different amq version. It appears that you are in a similar boat. So am I out of luck here and should simply run with my local modifications? I'm caught in a hard spot here as our objective is transparent JMS and AMQ regardless of version. -- View this message in context: http://qpid.2158936.n2.nabble.com/Hard-coded-destination-parameters-prevent-creation-of-Producer-and-Consumer-tp7581160p7581325.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
