You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Keith W <ke...@gmail.com> on 2016/12/02 15:39:45 UTC
Detecting presence of AMQP-MANAGEMENT server capability from the Qpid
JMS Client
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 December 2016 at 18:29, Rob Godfrey <ro...@gmail.com> wrote:
> On 2 December 2016 at 19:03, Robbie Gemmell <ro...@gmail.com>
> wrote:
>
>> On 2 December 2016 at 17:36, Rob Godfrey <ro...@gmail.com> wrote:
>> > On 2 December 2016 at 17:13, Robbie Gemmell <ro...@gmail.com>
>> > 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> >> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: dev-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Rob Godfrey <ro...@gmail.com>.
I actually quite like this approach
--Rob
On 5 December 2016 at 12:40, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 5 December 2016 at 12:39, Robbie Gemmell <ro...@gmail.com>
> wrote:
> > On 3 December 2016 at 18:45, Keith W <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >
> > Yes, it looks like essentially every object in their impl does the same:
>
> http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.
> 0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/
> client/jms/JmsPropertyContext.html
>
> (Note to self, don't accidentally press whatever the kb shortcut for send
> is :P)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Robbie Gemmell <ro...@gmail.com>.
On 5 December 2016 at 12:39, Robbie Gemmell <ro...@gmail.com> wrote:
> On 3 December 2016 at 18:45, Keith W <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> Yes, it looks like essentially every object in their impl does the same:
http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/JmsPropertyContext.html
(Note to self, don't accidentally press whatever the kb shortcut for send is :P)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Robbie Gemmell <ro...@gmail.com>.
On 3 December 2016 at 18:45, Keith W <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
Yes, it looks like essentially every object in their impl does the same:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Keith W <ke...@gmail.com>.
>> >> 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Rob Godfrey <ro...@gmail.com>.
On 2 December 2016 at 19:03, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 2 December 2016 at 17:36, Rob Godfrey <ro...@gmail.com> wrote:
> > On 2 December 2016 at 17:13, Robbie Gemmell <ro...@gmail.com>
> > 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: dev-help@qpid.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 December 2016 at 17:36, Rob Godfrey <ro...@gmail.com> wrote:
> On 2 December 2016 at 17:13, Robbie Gemmell <ro...@gmail.com>
> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Rob Godfrey <ro...@gmail.com>.
On 2 December 2016 at 17:13, Robbie Gemmell <ro...@gmail.com>
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.
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
> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Detecting presence of AMQP-MANAGEMENT server capability from the
Qpid JMS Client
Posted by Robbie Gemmell <ro...@gmail.com>.
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.
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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org