On 2 December 2016 at 18:29, Rob Godfrey <[email protected]> wrote: > On 2 December 2016 at 19:03, Robbie Gemmell <[email protected]> > wrote: > >> 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 :) >> > > Yeah - I didn't say I *liked* the thought... but other than horribly > abusing JMSX properties in some way, that seemed like the only way to get > information about the connection in a "standardized" way. > > >> >> > 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. >> >> > Yeah - as far as implementing some upcoming AMQP standards, I think that > will become an issue... not sure where the best forum to discuss it is > though.. > > -- Rob > >
I think these would be discussed here at Qpid as implementation details before qualifying for discussion in other forums. >> > >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
