qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bhupendra.x.bhard...@jpmorgan.com
Subject Re: broker Java management interfaces
Date Mon, 28 Aug 2006 15:24:41 GMT
Hi Alan, 

Thanks for your comments and taking time to go through the interfaces.

Regarding your general question -  That's a good question and it is still 
an open question.  Robert did talk about it with me but it is still to be 
decided.  May be once he comes back from leave we can give some more 
thoughts to it.  Sorry, right now I am not in situation to give you a 
definite answer for that.

Specific comments- 
Yes, instead of giving a static type, the class.getName() can also be 
used.  I will make a note of it to discuss with Robert.  Using a static 
type only makes it more user readable and that I think must be the idea 
behind it.  Currently we are using jconsole as management tool, and till 
we have another tool, I think this is what the internal users of JPMC will 
be using.

And I did miss out the create Queue method. Creation and deletion of queue 
will also be part of the ManagedBroker interface. Thanks again for 
pointing that out.


Regards,
Bhupendra Bhardwaj







Alan Conway <aconway@redhat.com>
28/08/2006 14:56
Please respond to dev
 
        To:     dev@etp.108.redhat.com
        cc:     ibtech_blaze_developers@jpmorgan.com
        Subject:        Re: broker Java management interfaces


General question and some specific comments.

General question first: to what extent do we want the management
interfaces to duplicate functionality already available through the
protocol? The protocol allows you to create and delete queues,
exchanges, bindings etc.

Since dynamic control of brokers via the protocol itself is a stated
goal of the spec, should we instead be expanding the protocol to satisfy
management requirements?

Even if we need to support management via widely-used protocols like JMX
or SNMP, we could still provide management via the protocol and then
provide JXM/SNMP access, e.g. A JMX connector that speaks AMQP.

If we do want to go for enabling management in the protocol the Java
interfaces provide a great shopping list of what's missing.


Specific comments;

Why do you associate a static type with each class? Why not just use
Class.getName() to identify types? 

Looks like you're missing a createQueue method.

Cheers,
Alan.

On Mon, 2006-08-28 at 10:14 +0100, bhupendra.x.bhardwaj@jpmorgan.com
wrote:
> 
> Hi all, 
> 
> Please accept my greetings. 
> Here is my first email to the group.  I am working on Java management
> interfaces for the Broker and will be implementing the management
> features. After discussions with Robert J Greig, we have come up with
> a set of basic management features, which we would like to implement. 
> 
> I am attaching the Java interfaces with this email and would like to
> get your comments and suggestions for improvement.  I have added
> comments with the method declarations, but still let me know if you
> would like to get more clarification. 
> 
> 
> 
> 
> 
> Regards, 
> Bhupendra Bhardwaj 
> 
> 
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change
> without notice. Any comments or statements made herein do not
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
> 
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance thereon) is
> STRICTLY PROHIBITED. Although this transmission and any attachments
> are believed to be free of any virus or other defect that might affect
> any computer system into which it is received and opened, it is the
> responsibility of the recipient to ensure that it is virus free and no
> responsibility is accepted by JPMorgan Chase & Co., its subsidiaries
> and affiliates, as applicable, for any loss or damage arising in any
> way from its use. If you received this transmission in error, please
> immediately contact the sender and destroy the material in its
> entirety, whether in electronic or hard copy format. Thank you.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@etp.108.redhat.com
> For additional commands, e-mail: dev-help@etp.108.redhat.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@etp.108.redhat.com
For additional commands, e-mail: dev-help@etp.108.redhat.com




This communication is for informational purposes only. It is not intended as an offer or solicitation
for the purchase or sale of any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not warranted as to completeness
or accuracy and are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is privileged, confidential, legally privileged,
and/or exempt from disclosure under applicable law. If you are not the intended recipient,
you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission
and any attachments are believed to be free of any virus or other defect that might affect
any computer system into which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase
& Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising
in any way from its use. If you received this transmission in error, please immediately contact
the sender and destroy the material in its entirety, whether in electronic or hard copy format.
Thank you.
 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message