On 2 December 2016 at 17:36, Rob Godfrey <[email protected]> wrote: > On 2 December 2016 at 17:13, Robbie Gemmell <[email protected]> > wrote: > >> Yes, there wont currently be a way to do this, thus far the >> capabilities have only ever been used for things the client itself >> acts upon. Also, for any extended behaviour present thus far we have >> only used e.g vendor properties and such like within the existing API, >> and have resisted adding additional APIs beyond those provided by JMS. >> I'm not sure there is a facility we could use here for such things >> though, one to think about. >> >> > The only way I can think to expose this is via defining a format for the > JMSProviderName in the ConnectionMetaData that serializes the offered > capabilities and server side defined connection properties in some way. If > this was standardised then one could parse the version string to find out > the necessary information. >
At first thought it feels like that might be a stretch too far :) > As you point out this doesn't seem to be necessary for amqp management > (since the detection of $management" should be enough presuming you are not > talking to a service which auto-creates destinations... But other > properties/capabilities might affect how your application functions. > > Of much more interest to me (particularly in the use of AMQP management) is > the ability set properties on Destinations (through JNDI would suffice, > though also having a String format for Sessin.createQueue would be > better). In particular being able to control the local source/target > address (and possibly in future the link name). The "direct" request > response model requires that the client creates an receiving link with a > given target address (and a source address of $management)... the reply-to > on messages sent to $management is then that target address on the > consumer. Currently there is no way to achieve this with the JMS client :-( > > -- Rob > Indeed, we currently have no system in place for per-destination manipulations of the AMQP link details like that, only some bits around prefetch/settlement/redelivery etc. > >> 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? >> >> Robbie >> >> On 2 December 2016 at 15:39, Keith W <[email protected]> wrote: >> > Hi, >> > >> > In QPID-7556, we intend to advertise the Qpid Broker for Java AMQP >> > Management ability with an AMQP 1.0 open performative >> > offered-capability [1] of 'AMQP-MANAGEMENT'. >> > >> > As a user of the Qpid JMS Client, how do I detect that the server >> > offers this capability? >> > >> > At the moment, from what I see of the public API, I don't have a way >> > to check for an arbitrary server offered-capabilities. >> > AmqpConnectionProperties cherry picks the capabilities that are >> > currently known/interesting but there is no way to check for an >> > arbitrary one. >> > >> > AmqpConnectionProperties could be simply changed to detect the >> > AMQP-MANAGEMENT (isAmpqManagementSupported()), or it could offer an >> > API to the user could enquire on a particular capability. >> > >> > My use case is test automation. I need check whether I can use AMQP >> > Management so I may fallback back to an older management technique, >> > but, I believe the feature would have general utility. >> > >> > cheers Keith. >> > >> > >> > [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core- >> transport-v1.0-os.html#type-open >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
