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 > > > >> 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] > >
