I HAVE ATTEMPED TO UNSUBSCRIBE FROM THIS LIST MANY TIMES BUT IT DOES NOT
WORK. PLEASE HELP ME GET OFF THIS LIST.
JPMORGAN RPS | +: michael.j.billi...@jpmorgan.com | (: 816-673-3905
Rafael Schloming rafa...@redhat.com
03/20/2009 09:50 AM
Please respond to
dev@qpid.apache.org
To
dev@qpid.apache.org
cc
Subject
Re: AMQP 1.0
Aidan Skinner wrote:
On Thu, Mar 19, 2009 at 6:12 PM, Rafael Schloming rafa...@redhat.com
wrote:
Robert Godfrey wrote:
That is why I advocate an *interface* rather than casting into
implementation classes.
An interface if restricted to only permit features not accessible
through vanilla JMS would certainly help, but I still think casting as
part of the API unacceptably blurs the boundaries of the API. There is
no way to tell what types you're allowed to cast and which interfaces
you're allowed to cast it to.
I've always hated that about Java. I'm pretty firm on the
bondage-and-discipline side of the strong typing argument though, and
I realise others mileage may vary.
access to the same broker extension. I would probably add an assertion
based on the destination, broker vendor/version, etc to verify that the
broker and recipient will understand what is being sent.
I think if we implement non-standard features we should definitely do
this.
I understand that you have a pathalogical hatred of casts. The java
syntax is certainly less than ideal. However where we are depending
on AMQP specific behaviour it should be called out.
It's not casts I dislike. It's casting as part of an API that I dislike
since it makes the API unnecessarily blurry. It's also quite trivial to
avoid assuming you don't have a pathological hatred of static methods.
;)
are you talking about something like public static AMQDestination
toAMQDestination(javax.jms.Destination dest) and that does the cast
inside AMQDestination?
I was actually thinking about the message case, e.g.:
AMQMessage m = AMQMessage.fromJMSMessage(...)
or something like that. But you could do something similar with the
destination. Also, I wasn't necessarily thinking that you would cast
inside the static method, I think the decorator thing I mentioned
earlier is worthy of some exploration, but obviously one of the benefits
of having the method is we can change what it does later.
Hopefully most AMQP/QPID extensions can be isolated in cofiguration
rather than code...
I think the destination abstraction is a reasonably useful way to do
this for most things. It gives us one mechanism that is mostly used via
configuration but can also be used through code as well with
createQueue(...) and friends.
I'm a little confused, are we talking about client config or server
config?
I was thinking of client config, specifically what we've traditionally
referred to as the binding URL, although I've never actually
understood why it's a URL, and it really doesn't have all that much to
do with binding either, particularly in a 1-0 model.
I'm actually just thinking that text based config strings for
destinations can control a lot of the client behavior we care about,
e.g. ack policy, sync policy, prefetch, etc, and this has the benefit of
being usable from both a config file and from code, and it is sort of an
approved extension point in as much as JMS has them.
--Rafael
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Generally, this communication is for informational purposes only
and 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. In the event you are receiving the offering
materials attached below related to your interest in hedge funds or
private equity, this communication may be intended as an offer or
solicitation for the purchase or sale of such fund(s). 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,
