On 3 December 2016 at 18:45, Keith W <[email protected]> wrote: >>> >> For now, given you are presumably talking about the Qpid Java broker >>> >> here....can you simply try opening the link and have it fail if not >>> >> supported? I'd guess if you try to attach to the management address, >>> >> since it doesnt automatically create entities by default it would have >>> >> to refuse the link instead? > > Absolutely - this was actually my first thought. My difficultly is > that the tests need to work with the older protocols AMQP-0-8..0-10 > and older releases so I can't rely on a creating a producer against > $management explicitly failing. This lead me to look at whether AMQP > Management could be somehow detected up front from the Connection > object itself as a simpler way. There are workarounds I can take. > > I can't help but feel though that there will be other occasions when > the application might wish to know about the peer's > offered-capabilities and possibly the peer's open properties too, for > instance, for bug avoidance. I notice that Websphere MQ's > JmsConnectionMetaData [1] implements a java,util.Map in addition to > javax.jms.ConnectionMetaData. I don't actually know how they use it > but it strikes me it might offer a reasonablly unobtrusive way to > expose capabilities (as one map entry "capabilities" => List) and > properties (as another "properties" => Map). > > [1] > http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/JmsConnectionMetaData.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
Yes, it looks like essentially every object in their impl does the same: --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
