Aidan Skinner wrote:
On Thu, Mar 19, 2009 at 6:12 PM, Rafael Schloming <[email protected]> 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:[email protected]
