2009/3/19 Rajith Attapattu <[email protected]>:
> On Thu, Mar 19, 2009 at 9:40 AM, Aidan Skinner <[email protected]> wrote:
>> On Thu, Mar 19, 2009 at 1:29 PM, Rajith Attapattu <[email protected]> wrote:
>>> On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner <[email protected]> wrote:
>>>> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <[email protected]> wrote:
>>
>>>> The Java client uses JMS for this to an extent, but we still need a
>>>> way of exposing AMQP specific things in ways that are as version
>>>> independent as possible (such as the mandatory flag). I've been
>>>> kicking around the idea of something like this:
>>>>
>>>
>>> I am of the opinion that you could get 99% of the AMQP stuff while
>>> still using pure JMS.
>>> I have a few ideas around how to do the immediate flag etc while still
>>> using pure JMS.
>>> One such idea is to pass in a QPID specific property in the message
>>> called "AMQP_IMMEDIATE" and the respective sender method can look for
>>> the presense of this flag and put that in the delivery props. When
>>
>> See, I'm not sure this is really "pure JMS". It may not use any
>> non-JMS API, but it does rely on non-JMS semantics.
>>
>> I can easily see that this improves portability from a "does my code
>> compile" PoV. I think it may be quite unhelpful from a "does my code
>> still work" PoV however. Having non-JMS features available as non-JMS
>> API at least makes their dependence on this more obvious.
I completely agree with Aidan's point here.
Frankly if you are relying on AMQP specific semantics then you should
make this clear in the code.
Personally I would think
if(msg instanceof AMQMessage)
{
((AMQMessage)msg).setImmediate(true);
}
is entirely appropriate. Best would be if AMQMessage was defined by
the AMQP Working Group and provided in an org.amqp package...
[aside - immediate is a really terrible example here as it is not
something that exists in 1-0].
Using custom headers hides dependencies and makes things compile (or
link) even when they should fail.
Implementation wise the current (0-8/0-9) / 0-10 multiversion stuff is
a bit of / complete nightmare.
I think the 1-0 code should be *much more* separate from the existing code.
On the interfaces side, what I was saying was that AMQMessage need not
extend JMS Message, etc... Our *implementation* of a Message class
would likely implement both.
My main concern would be if there were any legal implications to
publishing a set of AMQP interfaces that depended on the JMS ones...
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
