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, 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. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.
