You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Justin Ross <jr...@apache.org> on 2013/01/23 16:30:23 UTC

[ANNOUNCE] Apache Qpid 0.20 released

The Apache Qpid community is pleased to announce the immediate
availability of Apache Qpid 0.20.

Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
messaging solution which implements the Advanced Message Queuing
Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
C++ and Java, along with clients for C++, Java JMS, .Net, Python,
Ruby, and Perl.

Qpid 0.20 is available from our website:

     http://qpid.apache.org/download.html

The 0.20 release includes many bug fixes and improvements.  We
recommend that all users upgrade.  A comprehensive list of changes in
the 0.20 release is available here:

     http://qpid.apache.org/release_notes_0.20.html

Thanks to all the users and contributors who have helped to improve
Apache Qpid.

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Rob Godfrey <ro...@gmail.com>.
On 26 January 2013 14:07, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi Rob,
> That looks exactly like it. Blimey how did you find the Jira so fast?? It's
> a serious question, I'm not too familiar with Jira in general (I've raised a
> few but that's about it). Is there a tutorial/FAQ/idiot's guide for finding
> things in Qpid Jira.
>

To be honest I searched in my Gmail folder for Qpid JIRAs for "java"
and "daemon" :-) ... I remembered the gist of the JIRA details because
I was involved in some discussions about it at the time.

Searching JIRA itself is normally a bit of a pain... though in this
case if you use the query functionality looking for JIRAs affecting
Qpid, component Java Client, fix version after 0.12 and containing the
word daemon, then you do get it:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20in%20%28%220.20%22%2C%20%220.19%22%2C%20%220.18%22%2C%20%220.17%22%2C%20%220.16%22%2C%20%220.15%22%2C%20%220.14%22%2C%20%220.13%22%29%20AND%20component%20%3D%20%22Java%20Client%22%20AND%20text%20~%20%22daemon%22

> The Jira comment "Investigating other providers suggests the typical
> behaviour is to make use of non-daemon threads by default" would fit with my
> observation of JBoss, and it looks like Alex observed the same with Tibco.
>
> Looking at the latest version of Programming in Apache Qpid I noticed:
>
> qpid.jms.daemon.dispatcher      boolean         false
>
> Controls whether the Session dispatcher thread is a daemon thread or not. If
> this system property is set to true then the Session dispatcher threads will
> be created as daemon threads. This setting is introduced in version 0.16.
>
>
> Which suggests this behaviour was introduced in 0.16
>
>
> FWIW I think that this is a good thing, and it's even better that it's
> configurable. I guess it's one of those changes that one doesn't notice
> until it's noticed :-)
>
> I'm liking the latest version of Programming in Apache Qpid, it looks like
> it has a lot more comprehensive documentation of the options in general.
>

Yeah - Keith, Robbie, Phil, Alex et. al have been doing good things to
the documentation... Still some way to go, but we are working on it.

> Thanks again for responding so fast Rob,

The issue you are having with List Messages didn't immediately ring
any bells for me... I'll have a quick look around to see if I can spot
anything.

Cheers,
Rob

> Frase
>
>
>
> On 26/01/13 12:10, Rob Godfrey wrote:
>>
>> On 26 January 2013 13:00, Fraser Adams <fr...@blueyonder.co.uk>
>> wrote:
>>>
>>> Another thing I've just noticed about 0.20 Java.
>>>
>>> The behaviour of the Thread that gets started when a MessageListener is
>>> registered has changed some time between 0.12 and 0.20 (I'm afraid I was
>>> stuck on 0.12 for a while so I can't say exactly which version it got
>>> changed in).
>>>
>> Are you referring to this change:
>>
>> https://issues.apache.org/jira/browse/QPID-3784
>>
>> -- Rob
>>
>>> In 0.12 it was a Daemon Thread, so things bombed straight out when main
>>> exited, in 0.20 it now appears to be a user Thread and it appears to
>>> block
>>> at the end of main and I have to ctrl C. (I think I've got Daemon and
>>> user
>>> the right way round...)
>>>
>>> I only really noticed this 'cause in some of the more noddy bits of code
>>> I've put together for tinkering I put
>>>
>>>          // Blocks here until return is pressed
>>>          try {
>>>              System.out.println("Hit Return to exit");
>>>              String s = commandLine.readLine();
>>>          } catch (Exception e) {
>>>              System.out.println ("ItemConsumer: exception: " +
>>> e.getMessage());
>>>              e.printStackTrace ();
>>>          }
>>>
>>> To stop things exiting immediately back in the 0.12 days, but now when I
>>> hit
>>> return the application stays running.
>>>
>>> I doubt it's a big deal and probably actually a useful change (TBH I'm
>>> not
>>> sure if the JMS spec says anything about this particular Thread). I know
>>> that JBoss Messaging behaved in this way so perhaps it's a common
>>> convention
>>> at least.
>>>
>>>
>>> As I say I don't think that this is an "issue" with 0.20, but it is a
>>> subtle
>>> change that affects how JMS MessageListener clients may need to behave.
>>>
>>> Frase
>>>
>>>> The Apache Qpid community is pleased to announce the immediate
>>>> availability of Apache Qpid 0.20.
>>>>
>>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>>>> messaging solution which implements the Advanced Message Queuing
>>>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>>>> Ruby, and Perl.
>>>>
>>>> Qpid 0.20 is available from our website:
>>>>
>>>>        http://qpid.apache.org/download.html
>>>>
>>>> The 0.20 release includes many bug fixes and improvements.  We
>>>> recommend that all users upgrade.  A comprehensive list of changes in
>>>> the 0.20 release is available here:
>>>>
>>>>        http://qpid.apache.org/release_notes_0.20.html
>>>>
>>>> Thanks to all the users and contributors who have helped to improve
>>>> Apache Qpid.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Rob,
That looks exactly like it. Blimey how did you find the Jira so fast?? 
It's a serious question, I'm not too familiar with Jira in general (I've 
raised a few but that's about it). Is there a tutorial/FAQ/idiot's guide 
for finding things in Qpid Jira.

The Jira comment "Investigating other providers suggests the typical 
behaviour is to make use of non-daemon threads by default" would fit 
with my observation of JBoss, and it looks like Alex observed the same 
with Tibco.

Looking at the latest version of Programming in Apache Qpid I noticed:

qpid.jms.daemon.dispatcher 	boolean 	false 	

Controls whether the Session dispatcher thread is a daemon thread or 
not. If this system property is set to true then the Session dispatcher 
threads will be created as daemon threads. This setting is introduced in 
version 0.16.


Which suggests this behaviour was introduced in 0.16


FWIW I think that this is a good thing, and it's even better that it's 
configurable. I guess it's one of those changes that one doesn't notice 
until it's noticed :-)

I'm liking the latest version of Programming in Apache Qpid, it looks 
like it has a lot more comprehensive documentation of the options in 
general.

Thanks again for responding so fast Rob,
Frase


On 26/01/13 12:10, Rob Godfrey wrote:
> On 26 January 2013 13:00, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>> Another thing I've just noticed about 0.20 Java.
>>
>> The behaviour of the Thread that gets started when a MessageListener is
>> registered has changed some time between 0.12 and 0.20 (I'm afraid I was
>> stuck on 0.12 for a while so I can't say exactly which version it got
>> changed in).
>>
> Are you referring to this change:
>
> https://issues.apache.org/jira/browse/QPID-3784
>
> -- Rob
>
>> In 0.12 it was a Daemon Thread, so things bombed straight out when main
>> exited, in 0.20 it now appears to be a user Thread and it appears to block
>> at the end of main and I have to ctrl C. (I think I've got Daemon and user
>> the right way round...)
>>
>> I only really noticed this 'cause in some of the more noddy bits of code
>> I've put together for tinkering I put
>>
>>          // Blocks here until return is pressed
>>          try {
>>              System.out.println("Hit Return to exit");
>>              String s = commandLine.readLine();
>>          } catch (Exception e) {
>>              System.out.println ("ItemConsumer: exception: " +
>> e.getMessage());
>>              e.printStackTrace ();
>>          }
>>
>> To stop things exiting immediately back in the 0.12 days, but now when I hit
>> return the application stays running.
>>
>> I doubt it's a big deal and probably actually a useful change (TBH I'm not
>> sure if the JMS spec says anything about this particular Thread). I know
>> that JBoss Messaging behaved in this way so perhaps it's a common convention
>> at least.
>>
>>
>> As I say I don't think that this is an "issue" with 0.20, but it is a subtle
>> change that affects how JMS MessageListener clients may need to behave.
>>
>> Frase
>>
>>> The Apache Qpid community is pleased to announce the immediate
>>> availability of Apache Qpid 0.20.
>>>
>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>>> messaging solution which implements the Advanced Message Queuing
>>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>>> Ruby, and Perl.
>>>
>>> Qpid 0.20 is available from our website:
>>>
>>>        http://qpid.apache.org/download.html
>>>
>>> The 0.20 release includes many bug fixes and improvements.  We
>>> recommend that all users upgrade.  A comprehensive list of changes in
>>> the 0.20 release is available here:
>>>
>>>        http://qpid.apache.org/release_notes_0.20.html
>>>
>>> Thanks to all the users and contributors who have helped to improve
>>> Apache Qpid.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Rob Godfrey <ro...@gmail.com>.
On 26 January 2013 13:00, Fraser Adams <fr...@blueyonder.co.uk> wrote:
>
> Another thing I've just noticed about 0.20 Java.
>
> The behaviour of the Thread that gets started when a MessageListener is
> registered has changed some time between 0.12 and 0.20 (I'm afraid I was
> stuck on 0.12 for a while so I can't say exactly which version it got
> changed in).
>

Are you referring to this change:

https://issues.apache.org/jira/browse/QPID-3784

-- Rob

> In 0.12 it was a Daemon Thread, so things bombed straight out when main
> exited, in 0.20 it now appears to be a user Thread and it appears to block
> at the end of main and I have to ctrl C. (I think I've got Daemon and user
> the right way round...)
>
> I only really noticed this 'cause in some of the more noddy bits of code
> I've put together for tinkering I put
>
>         // Blocks here until return is pressed
>         try {
>             System.out.println("Hit Return to exit");
>             String s = commandLine.readLine();
>         } catch (Exception e) {
>             System.out.println ("ItemConsumer: exception: " +
> e.getMessage());
>             e.printStackTrace ();
>         }
>
> To stop things exiting immediately back in the 0.12 days, but now when I hit
> return the application stays running.
>
> I doubt it's a big deal and probably actually a useful change (TBH I'm not
> sure if the JMS spec says anything about this particular Thread). I know
> that JBoss Messaging behaved in this way so perhaps it's a common convention
> at least.
>
>
> As I say I don't think that this is an "issue" with 0.20, but it is a subtle
> change that affects how JMS MessageListener clients may need to behave.
>
> Frase
>
>> The Apache Qpid community is pleased to announce the immediate
>> availability of Apache Qpid 0.20.
>>
>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>> messaging solution which implements the Advanced Message Queuing
>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>> Ruby, and Perl.
>>
>> Qpid 0.20 is available from our website:
>>
>>       http://qpid.apache.org/download.html
>>
>> The 0.20 release includes many bug fixes and improvements.  We
>> recommend that all users upgrade.  A comprehensive list of changes in
>> the 0.20 release is available here:
>>
>>       http://qpid.apache.org/release_notes_0.20.html
>>
>> Thanks to all the users and contributors who have helped to improve
>> Apache Qpid.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Another thing I've just noticed about 0.20 Java.

The behaviour of the Thread that gets started when a MessageListener is 
registered has changed some time between 0.12 and 0.20 (I'm afraid I was 
stuck on 0.12 for a while so I can't say exactly which version it got 
changed in).

In 0.12 it was a Daemon Thread, so things bombed straight out when main 
exited, in 0.20 it now appears to be a user Thread and it appears to 
block at the end of main and I have to ctrl C. (I think I've got Daemon 
and user the right way round...)

I only really noticed this 'cause in some of the more noddy bits of code 
I've put together for tinkering I put

         // Blocks here until return is pressed
         try {
             System.out.println("Hit Return to exit");
             String s = commandLine.readLine();
         } catch (Exception e) {
             System.out.println ("ItemConsumer: exception: " + 
e.getMessage());
             e.printStackTrace ();
         }

To stop things exiting immediately back in the 0.12 days, but now when I 
hit return the application stays running.

I doubt it's a big deal and probably actually a useful change (TBH I'm 
not sure if the JMS spec says anything about this particular Thread). I 
know that JBoss Messaging behaved in this way so perhaps it's a common 
convention at least.


As I say I don't think that this is an "issue" with 0.20, but it is a 
subtle change that affects how JMS MessageListener clients may need to 
behave.

Frase

> The Apache Qpid community is pleased to announce the immediate
> availability of Apache Qpid 0.20.
>
> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
> messaging solution which implements the Advanced Message Queuing
> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
> Ruby, and Perl.
>
> Qpid 0.20 is available from our website:
>
>       http://qpid.apache.org/download.html
>
> The 0.20 release includes many bug fixes and improvements.  We
> recommend that all users upgrade.  A comprehensive list of changes in
> the 0.20 release is available here:
>
>       http://qpid.apache.org/release_notes_0.20.html
>
> Thanks to all the users and contributors who have helped to improve
> Apache Qpid.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
No need to apologise, it's all cool.

I think that there's a degree of serendipity in all this in that it 
serves as a concrete example in the discussion on user/dev and the fact 
that it's sometimes a grey area with some of us users doing crazy things :-)

I think the encoding discussion is a really interesting one to have had 
and it's good to hear the different perspectives, plenty of good food 
for thought.

> Agreed again. We didn't do a good enough job in thinking about 
> backward compatibility and the impact of the change to existing users. 
> I failed to mentally join up all the dots sufficiently and apologise 
> for that. Glad it is all working again now though without too much work!
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Gordon Sim <gs...@redhat.com>.
On 01/29/2013 08:42 PM, Fraser Adams wrote:
> I don't know about the
> specification document per se, but that JavaDoc for ObjectMessage says:
> "An |ObjectMessage| object is used to send a message that contains a
> serializable object in the Java programming language ("Java object")".
>
> Being pedantic :-) it says *a* serializable object not *any*
> serializable object, so I could argue that a Map containing any type
> that has a defined AMQP mapping to Java is also serializable, so does
> actually conform to the spec (unless there's something formal that
> actually does say *any* serializable Object).

I think the important question in questions of compliance with the spec 
is what might break.

I suspect that there are many applications using ObjectMessage that put 
other Serializable objects other than primitives, collections and 
strings. I would want such applications to continue to work using qpid, 
though obviously the encoded bytes of the message would likely only be 
usable in java receivers.

Likewise applications sending simple (non-nested) maps, should continue 
to work as expected. here we can quite legitimately encode them in the 
AMQP type system and that has the advantage of allowing non-java clients 
to participate in such conversations.

Where we would fail now is in providing the guarantee that a received 
MapMessage will never contain nested maps or lists. That could break 
some applications, though of course in those cases the application most 
likely wouldn't actually be able to process the message at all (unless 
of course they were additionally able to handle it as an ObjectMessage 
enclosing a map!). Having some means of turning on a strict 
interpretation would be nice. I.e. with that setting on such an incoming 
message could not be cast to a MapMessage. That may start making the 
code more complex of course, its an ideal though, I would say.

> Of course I'm now just being facetious :-) I completely agree with the
> "provided you can explicitly control the encoding " I think ultimately
> that's the bit that's currently missing from the Java bindings, as we've
> already discussed. I think that it's good to have these conversations I
> find them really interesting (how sad am I). It's fascinating to get the
> perspective of others around interpretations of specifications etc. .

Agreed!

[...]
> That's fair enough <facetious>providing that it doesn't break code that
> was using the previous interface</facetious>

Agreed again. We didn't do a good enough job in thinking about backward 
compatibility and the impact of the change to existing users. I failed 
to mentally join up all the dots sufficiently and apologise for that. 
Glad it is all working again now though without too much work!



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
> I think that approach deviates from the spec in a similar sort of 
> subtle way the use of MapMessage does, i.e. you can't send any 
> Serializable object in the map or list. 
> I do accept it provides quite a nice and consistent interface provided 
> you can explicitly control the encoding to use when sending.

It's an interesting conversation piece. I don't know about the 
specification document per se, but that JavaDoc for ObjectMessage says: 
"An |ObjectMessage| object is used to send a message that contains a 
serializable object in the Java programming language ("Java object")".

Being pedantic :-) it says *a* serializable object not *any* 
serializable object, so I could argue that a Map containing any type 
that has a defined AMQP mapping to Java is also serializable, so does 
actually conform to the spec (unless there's something formal that 
actually does say *any* serializable Object).

Of course I'm now just being facetious :-) I completely agree with the 
"provided you can explicitly control the encoding " I think ultimately 
that's the bit that's currently missing from the Java bindings, as we've 
already discussed. I think that it's good to have these conversations I 
find them really interesting (how sad am I). It's fascinating to get the 
perspective of others around interpretations of specifications etc. .

>
>
>> I'm not violently opposed to "Being able to treat it as some other
>> message type may also be reasonable. " and I know from our conversations
>> wrt. Proton that you've got some views with respect to providing choice.
>> That's kind of fair, though my *personal* view is that it's ultimately a
>> good idea to provide consistency and encourage common design patterns.
>
> Yes, choice can be good but it can sometimes by unnecessary and 
> confusing. In this particular case my view is that if an application 
> is able to handle one of the message types and you could expose the 
> data to them in a way that makes sense, why not do so.
That's fair enough <facetious>providing that it doesn't break code that 
was using the previous interface</facetious>

Fortunately none of this wound up being too big a deal for me as I'd 
already abstracted my Map and List handling into a helper class because 
a) I hate working with MapMessage (did I mention that :-)) and b) I had 
a hunch that List support may change and I also wanted to hide the low 
level encoding/decoding to BytesMessage. So it was easy enough to add an 
extra test for MapMessage in my code for amqp/list. In the latest 
release I've also added some extra abstractions for testing for 
amqp/list and amqp/map because I'm currently down-casting to the 
underlying Qpid Message to do getContentType() which is a bit ugly and 
could break in some future Qpid release.

I was quite relieved that *encoding* amqp/list via BytesMessage was 
still supported. That would have been a lot more of a pain than decoding 
'cause I can defensively code for the decode, but not for the encode so 
that would have required specific code changes for pre 0.20 and 0.20 on, 
fortunately that's not the case so the single code base should work 
across all versions now.

Thanks for all your thoughts on this, it's always fun to chat around 
this stuff.

Frase

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Gordon Sim <gs...@redhat.com>.
On 01/29/2013 07:48 PM, Fraser Adams wrote:
> When I said "ObjectMessage is the only way to expose amqp/map and
> amqp/list" I did caveat that with "and properly conform to the spec. "
> :-)

I think that approach deviates from the spec in a similar sort of subtle 
way the use of MapMessage does, i.e. you can't send any Serializable 
object in the map or list.

I do accept it provides quite a nice and consistent interface provided 
you can explicitly control the encoding to use when sending.

> I'm not violently opposed to "Being able to treat it as some other
> message type may also be reasonable. " and I know from our conversations
> wrt. Proton that you've got some views with respect to providing choice.
> That's kind of fair, though my *personal* view is that it's ultimately a
> good idea to provide consistency and encourage common design patterns.

Yes, choice can be good but it can sometimes by unnecessary and 
confusing. In this particular case my view is that if an application is 
able to handle one of the message types and you could expose the data to 
them in a way that makes sense, why not do so.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Thanks for the response Gordon. I'll look at the qpid specific 
ListMessage for the next release of my QMF stuff. I only noticed the 
MapMessage encoding at the weekend and I wanted to get something up and 
working for Qpid 0.20. I wasn't too happy with the MapMessage especially 
as there's no way to get the size() so getting from that to the 
java.util.List that things like my getObjects() returns required me to 
create an ArrayList with an arbitrary size.

Re the other points in this thread. I think that we are converging :-) 
I'm pleased that you agree with the comments on exposing Content-Type, I 
really do think that this is the way to go to allow clients to be clear 
on things.


When I said "ObjectMessage is the only way to expose amqp/map and 
amqp/list" I did caveat that with "and properly conform to the spec. " 
:-) I'm not violently opposed to "Being able to treat it as some other 
message type may also be reasonable. " and I know from our conversations 
wrt. Proton that you've got some views with respect to providing choice. 
That's kind of fair, though my *personal* view is that it's ultimately a 
good idea to provide consistency and encourage common design patterns.

<obtuse>To be fair my comment about the spec. wasn't *entirely* correct, 
BytesMessage plus a private encoding also conformed to the spec, though 
I'd definitely agree that this wasn't the friendliest thing in the world 
to use - I'd never have worked that out without your little code snippet 
:-)</obtuse>


Re "If I send a simple map, receiving it from JMS as a MapMessage seems 
reasonable" - being very glib IMHO there's nothing terribly reasonable 
about MapMessage :-) I *really* don't know why I'm so prejudiced against 
MapMessage, but for some reason I've got a violent dislike for it :-/ it 
must have had bad karma from a previous life. I *think* that it stems 
from it feeling a bit old fashioned and rather inconsistent. When Sun 
introduced Collections there came a good range of consistent interfaces, 
which meant that one rarely needs to use things like HashTable etc., but 
MapMessage is a bit stuck in those dark ages, not being able to get a 
size and having to use Enumerations to iterate kind of offend me :-) And 
I can't stick anything in if aside from a primitive a String or a byte[] 
(well if I read the spec :-p)

So thanks again, I think that we've got a good set of common ground even 
if we don't agree 100% on everything (I'm bound to bang on about the 
spec. at some point again :-))

Cheers,
Frase

On 29/01/13 19:05, Gordon Sim wrote:
> On 01/29/2013 06:44 PM, Fraser Adams wrote:
>>  From your comment below are you saying that this is exposed in a choice
>> of three forms. It appeared to me as an instanceof MapMessage - how
>> would I get it to behave as say a org.apache.qpid.jms.ListMessage? is
>> there a config option or can I just cast it?
>
> You should be able to cast it to MapMessage, StreamMessage or the qpid 
> specific ListMessage, whatever suits best. Being additionally able to 
> cast to a BytesMessage or an ObjectMessage would I think be great 
> barring any issues with that I might be missing. My view in short is 
> that if the data can be exposed through a particular interface than we 
> should do so if requested.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Gordon Sim <gs...@redhat.com>.
On 01/29/2013 06:44 PM, Fraser Adams wrote:
>  From your comment below are you saying that this is exposed in a choice
> of three forms. It appeared to me as an instanceof MapMessage - how
> would I get it to behave as say a org.apache.qpid.jms.ListMessage? is
> there a config option or can I just cast it?

You should be able to cast it to MapMessage, StreamMessage or the qpid 
specific ListMessage, whatever suits best. Being additionally able to 
cast to a BytesMessage or an ObjectMessage would I think be great 
barring any issues with that I might be missing. My view in short is 
that if the data can be exposed through a particular interface than we 
should do so if requested.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Aha, thanks for that - asList() sound like just the thing for me. I'll 
make use of that in my next release. Wish I'd realised that at the weekend.

I feel a bit happier now. Hopefully the conversation around 
ObjectMessage and Content-Type has struck a chord with you too, 
hopefully it has teased out some interesting food for thought. I'm 
certainly pleased that there's been some convergence in thought 
processes, plus it's the sort of thing that stimulates the old "grey 
matter".

In retrospect I *really wish* I'd chipped in when this was first raised, 
that'll teach me for "parking" something because I wanted to "focus" :-D

Cheers,
Frase
> You can cast it to the said interface.
> List message interface has a method called asList() to retrieve a
> java.util.List or you can use methods like get(int index)
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support - oh dear! again.....

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 12/02/13 14:49, Rajith Attapattu wrote:
> Fraser,
>
> It seems that map message would probably be your choice.
:-(

Sound of (guitarists) fingernails scraping down a blackboard.......... 
to be fair MapMessage certainly wouldn't be my choice :-) but given the 
options.......
> I agree it's quite hideous.
There's a Scottish expression "nae very bonny" that sums it up nicely.....
>
> Another option I floated (and the majority didn't like it) was to have
> the list as a single entry in the map instead of having to do
> map.getObject("1").
It's all varying degrees of hideousness. So if I *have* to suffer the 
indignity of a MapMessage breaking the spec I'm tempted to suggest that 
map.getObject("amqp/list"); is no worse than any other option and 
somewhat does what it says on the tin. I guess that the problem now is 
we've now got a MapMessage with indices mapped to keys deployed in a 
Qpid release, so any changes will now break things for anyone using it.
>
> So you can do something like List list = (List)map.getObject("list")
> and then work with the list.
> A good compromise would be to have both approaches in the MapMessage
> interface for the List message.
So how would having both approaches work? Wouldn't you end up storing 
the data twice, once as the List and again as the items in the list 
keyed by indices? I'm sure that there's some storage cleverness that 
could be done but possibly a lot of effort. The lack of size() in 
MapMessage complicates things, so getting the list is nice enough but if 
anyone wants to mess around using the indices approach there's no way of 
knowing what the last value is - so then you'd have to Enumerate 
explicitly discarding the extra item with the "amqp/list" key.


Seriously, I know it's a soap box of mine but *please* think about the 
current MapMessage andObjectMessage and better ContentType exposure. 
I've tried to think through various permutations, but TBH nothing has 
yet convinced me that it's not the most "consistent" approach given that 
it can be done using existing JMS and Java Collection interfaces and as 
an idiom it's pretty consistent with qpid::messaging using content-type 
and Variant::Map/Variant::List.

I've stuck with Enumerating the current MapMessage for now 'cause at 
least it works.

Cheers,
Frase


>
> Rajith
>
> On Fri, Feb 8, 2013 at 4:31 AM, Fraser Adams
> <fr...@blueyonder.co.uk> wrote:
>> Hi Guys,
>> I was planning on having a look at the org.apache.qpid.jms.ListMessage stuff
>> and move away from the cast to MapMessage, but a somewhat irksome thought
>> struck me before I got started.
>>
>> As the moment my QMF2 code can compile against more or less any version of
>> the Qpid Java client runtime. I needed to include a specific target to build
>> a patched AMQPMessageDelegate_0_10.java for versions below 0.10 but
>> everything else should currently just compile.
>>
>>
>> I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so if I
>> actually use it compilation will break for everything else :-(
>>
>> I'm not wildly keen on the MapMessage approach as you know, both for
>> "philosophical reasons :-)" and because I can't get the size() so I need to
>> "make up" a size for the ArrayList that I copy the elements from the
>> MapMessage into. The asList() method on ListMessage looked to be the nicest
>> option from the recent threads.
>>
>>
>> So I'm thinking that I'm going to either:
>> a) Have to stick with MapMessage 'cause I know that compiles across the
>> board, but it offends me rather.
>> b) have a specific target for 0.20 onwards, which I don't especially like
>> either.
>> c) Use reflection to find the asList(), which should be do-able and has a
>> certain entertainment value, but I suspect will probably be less efficient
>> than just living with the MapMessage inefficiencies - I can't say for sure,
>> any thoughts on that?
>>
>>
>> Does anybody have any better suggestions than those that'll allow me to use
>> lists across different Qpid releases without needing different builds?
>>
>>
>> Did I mention I preferred ObjectMessage :-) so this'll be another reason why
>> I do :-D
>>
>> Cheers,
>> Frase
>>
>>
>> On 29/01/13 20:18, Rajith Attapattu wrote:
>>> You can cast it to the said interface.
>>> List message interface has a method called asList() to retrieve a
>>> java.util.List or you can use methods like get(int index)
>>>
>>> If you use -Dqpid.use_legacy_stream_message=false, then the sender
>>> could work with the standard stream message interface and it will get
>>> sent on the wire as a List Message.
>>> On the receiver side, you could use the stream message methods as well.
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support - oh dear! again.....

Posted by Rajith Attapattu <ra...@gmail.com>.
Fraser,

It seems that map message would probably be your choice.
I agree it's quite hideous.

Another option I floated (and the majority didn't like it) was to have
the list as a single entry in the map instead of having to do
map.getObject("1").

So you can do something like List list = (List)map.getObject("list")
and then work with the list.
A good compromise would be to have both approaches in the MapMessage
interface for the List message.

Rajith

On Fri, Feb 8, 2013 at 4:31 AM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> Hi Guys,
> I was planning on having a look at the org.apache.qpid.jms.ListMessage stuff
> and move away from the cast to MapMessage, but a somewhat irksome thought
> struck me before I got started.
>
> As the moment my QMF2 code can compile against more or less any version of
> the Qpid Java client runtime. I needed to include a specific target to build
> a patched AMQPMessageDelegate_0_10.java for versions below 0.10 but
> everything else should currently just compile.
>
>
> I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so if I
> actually use it compilation will break for everything else :-(
>
> I'm not wildly keen on the MapMessage approach as you know, both for
> "philosophical reasons :-)" and because I can't get the size() so I need to
> "make up" a size for the ArrayList that I copy the elements from the
> MapMessage into. The asList() method on ListMessage looked to be the nicest
> option from the recent threads.
>
>
> So I'm thinking that I'm going to either:
> a) Have to stick with MapMessage 'cause I know that compiles across the
> board, but it offends me rather.
> b) have a specific target for 0.20 onwards, which I don't especially like
> either.
> c) Use reflection to find the asList(), which should be do-able and has a
> certain entertainment value, but I suspect will probably be less efficient
> than just living with the MapMessage inefficiencies - I can't say for sure,
> any thoughts on that?
>
>
> Does anybody have any better suggestions than those that'll allow me to use
> lists across different Qpid releases without needing different builds?
>
>
> Did I mention I preferred ObjectMessage :-) so this'll be another reason why
> I do :-D
>
> Cheers,
> Frase
>
>
> On 29/01/13 20:18, Rajith Attapattu wrote:
>>
>> You can cast it to the said interface.
>> List message interface has a method called asList() to retrieve a
>> java.util.List or you can use methods like get(int index)
>>
>> If you use -Dqpid.use_legacy_stream_message=false, then the sender
>> could work with the standard stream message interface and it will get
>> sent on the wire as a List Message.
>> On the receiver side, you could use the stream message methods as well.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

JMS List support - oh dear! again.....

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Guys,
I was planning on having a look at the org.apache.qpid.jms.ListMessage 
stuff and move away from the cast to MapMessage, but a somewhat irksome 
thought struck me before I got started.

As the moment my QMF2 code can compile against more or less any version 
of the Qpid Java client runtime. I needed to include a specific target 
to build a patched AMQPMessageDelegate_0_10.java for versions below 0.10 
but everything else should currently just compile.


I'm guessing that org.apache.qpid.jms.ListMessage was added in 0.20, so 
if I actually use it compilation will break for everything else :-(

I'm not wildly keen on the MapMessage approach as you know, both for 
"philosophical reasons :-)" and because I can't get the size() so I need 
to "make up" a size for the ArrayList that I copy the elements from the 
MapMessage into. The asList() method on ListMessage looked to be the 
nicest option from the recent threads.


So I'm thinking that I'm going to either:
a) Have to stick with MapMessage 'cause I know that compiles across the 
board, but it offends me rather.
b) have a specific target for 0.20 onwards, which I don't especially 
like either.
c) Use reflection to find the asList(), which should be do-able and has 
a certain entertainment value, but I suspect will probably be less 
efficient than just living with the MapMessage inefficiencies - I can't 
say for sure, any thoughts on that?


Does anybody have any better suggestions than those that'll allow me to 
use lists across different Qpid releases without needing different builds?


Did I mention I preferred ObjectMessage :-) so this'll be another reason 
why I do :-D

Cheers,
Frase


On 29/01/13 20:18, Rajith Attapattu wrote:
> You can cast it to the said interface.
> List message interface has a method called asList() to retrieve a
> java.util.List or you can use methods like get(int index)
>
> If you use -Dqpid.use_legacy_stream_message=false, then the sender
> could work with the standard stream message interface and it will get
> sent on the wire as a List Message.
> On the receiver side, you could use the stream message methods as well.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jan 29, 2013 at 1:44 PM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> Hi Rajith,
> Yeah I realise in retrospect that it was discussed, I guess that my point is
> that it was only really flagged the once on the User mailing list and it
> passed my by largely as I was looking at other things. That's why I was
> using it as an example to back up Gordon's comment about unifying
> communication on the user and development list.

I do agree that this is a problem and have voiced my support for
unifying our mailing lists.

> From your comment below are you saying that this is exposed in a choice of
> three forms. It appeared to me as an instanceof MapMessage - how would I get
> it to behave as say a org.apache.qpid.jms.ListMessage? is there a config
> option or can I just cast it?

You can cast it to the said interface.
List message interface has a method called asList() to retrieve a
java.util.List or you can use methods like get(int index)

If you use -Dqpid.use_legacy_stream_message=false, then the sender
could work with the standard stream message interface and it will get
sent on the wire as a List Message.
On the receiver side, you could use the stream message methods as well.

> I don't suppose that you happened to make org.apache.qpid.jms.ListMessage
> implement java.util.List as well as javax.jms.Message?? :-) You say "it
> provides methods like the ones in java.util.List " but does it actually
> implement that interface?
>
> Re "for the client to provide out of the box support instead of receiving as
> bytes messages and having to decode the payload themselves. ". I've got
> sympathy with this for sure - I guess I was just bitten by the change and
> also as I've stated my personal view is that the correct approach is to use
> ObjectMessage. I'm not sure I'm winning that argument with yourself and
> Gordon, but I will keep banging on about it :-) I'd be interested to know
> what others think about this. As I said in my reply to Gordon a combination
> of List/Map in ObjectMessage plus exposing AMQP Content-Type will a)
> maximise consistency between JMS and qpid::messaging and b) keep within the
> JMS spec. Both of these are IMHO a really good thing.
>
> Regards,
> Frase.
>
>
>
> On 29/01/13 16:27, Rajith Attapattu wrote:
>>
>> Hey Fraser,
>>
>> The patch was extensively discussed here
>> https://reviews.apache.org/r/6816/
>> We expose the List message using
>> 1. Map Message
>> 2. Stream Message
>> 3. org.apache.qpid.jms.ListMessage
>>
>> I personally don't like the Map Message approach (see my comments on
>> the above review request).
>> I also think it's hideous.
>>
>> But you might like the ListMessage interface as it provides methods
>> like the ones in java.util.List
>>
>> The point of adding list message support is for the client to provide
>> out of the box support instead of receiving as bytes messages and
>> having to decode the payload themselves.
>>
>> Regards,
>>
>> Rajith
>>
>> On Sat, Jan 26, 2013 at 10:43 AM, Fraser Adams
>> <fr...@blueyonder.co.uk> wrote:
>>>
>>> As a follow up to my posting below.
>>>
>>> QMF2 is indeed broken by Java changes in Qpid 0.20 and my hunch around
>>> somebody messing with how Content-Type amqp/list is encoded and decoded
>>> does
>>> indeed look to be "the smoking gun".
>>>
>>> I added some debug code to my getObjects() and I was hitherto receiving a
>>> BytesMessage, which did need some decoding to retrieve the List, but now
>>> it
>>> is receiving a MapMessage.
>>>
>>> I've only started looking, but doing:
>>>
>>> MapMessage m = (MapMessage)response;
>>> for (Enumeration e = m.getMapNames() ; e.hasMoreElements() ;)
>>> {
>>>      String key = (String)e.nextElement();
>>> System.out.println("key = " + key);
>>> }
>>>
>>> indicates (for the "broker" object) "key = 0"
>>>
>>> Which is suggesting that Lists now seem to be encoded in MapMessages with
>>> keys that are indices :'( .
>>>
>>>
>>>
>>> To be fair Rajith Attapattu did post on this subject at the end of
>>> August:
>>>
>>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>>>
>>> and perhaps I *should* have taken more notice, however it was a single
>>> posting and pretty inconclusive, so I don't thing that it was
>>> unreasonable
>>> for me to park it in "things to look at once the QMF stuff is released"
>>> given where I was trying to focus my spare time.
>>>
>>>
>>> IMHO this is *exactly* the sort of thing that acts as a "/quod erat
>>> demonstrandum/" to Gordon Sim's posting on "mailing lists and fragmented
>>> communication", 'cause I'd have got a *whole lot more* animated about the
>>> subject if I'd have thought that this stuff was going to actually make it
>>> in
>>> to a release (see below!!).....
>>>
>>> Have I just missed where the release notes communicated this, or is this
>>> a
>>> change that hasn't been communicated to "users" (aside from Rajith's
>>> posting)??
>>>
>>>
>>>
>>> I have to say that IMHO whilst the BytesMessage stuff (and the associated
>>> decoding) "wasn't exactly ideal" I think that the way MapMessage has been
>>> used here using String keys as indices feels pretty hideous too :-(
>>>
>>> There was some talk too in Rajith's post around "Make the list message
>>> accessible via the MapMessage and StreamMessage interfaces" I'm not sure
>>> if
>>> this has been done, but TBH I'm not sure that I like StreamMessage any
>>> better!!
>>>
>>>
>>>
>>> At the risk of coming over a bit anally retentive.......Here's what I
>>> should
>>> have taken the time to respond to
>>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>>> with:
>>>
>>>
>>> I don't actually like MapMessage a whole lot more than any of the above.
>>> I
>>> think that even for exposing amqp/map its use is flawed for (at least)
>>> two
>>> reasons:
>>> 1) MapMessage is frankly a hideous interface that should have been kicked
>>> into touch years ago by Sun. The particular axe I've got to grind with it
>>> is
>>> that there's this thing called java.util.Map which has been around since
>>> Java 1.2, so it's spectacularly unhelpful to have a different interface
>>> for
>>> Maps transported via JMS. Among other things It really bugs me having to
>>> use
>>> Enumerations and not being able to use foreach.
>>>
>>> It's even more irksome becase QMF often comprises Maps of Maps, so the
>>> top
>>> level Map ends up being a MapMessage and the rest end up being
>>> java.util.Map. It's not at all elegant and frankly I ended up writing a
>>> "getMap(final Message message)" method that populates a java.util.Map
>>> with
>>> the messageProperties and Map values so I'd get at least some
>>> consistency.
>>>
>>> 2) Possibly the main reason using MapMessage is flawed though is because
>>> the
>>> JMS Spec says:
>>> "A |MapMessage| object is used to send a set of name-value pairs. The
>>> names
>>> are |String| objects, and the values are *primitive data types in the
>>> Java
>>> programming language*", that's right "primitive data types". To be fair
>>> it
>>> then goes on to include byte[] in the list and it *does* include a
>>> getObject() and setObject(), but the JavaDoc explicitly says "This method
>>> works only for the objectified primitive object types (|Integer|,
>>> |Double|,
>>> |Long| ...), |String| objects, and byte arrays. ".
>>>
>>>
>>> So the bottom line is then that encoding java.util.Map and java.util.List
>>> into javax.jms.MapMessage (which are clearly necessary for QMF plus a
>>> whole
>>> load of other things) *explicitly* breaks the JMS specification (as well
>>> as
>>> having a really hideous interface).
>>>
>>> As for StreamMessage that says:
>>> "A |StreamMessage| object is used to send a stream of primitive types in
>>> the
>>> Java programming language" and the writeObject() method JavaDoc says
>>> "This
>>> method works only for the objectified primitive object types (|Integer|,
>>> |Double|, |Long| ...), |String| objects, and byte arrays. ". So again
>>> explicitly primitive types.
>>>
>>>
>>> I've said the following a couple of times on the Qpid Users mailing list,
>>> but nobody has yet bitten, hopefully this issue might start the
>>> discussion
>>> again....
>>>
>>> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a
>>> way
>>> that doesn't break the JMS specification is to use
>>> javax.jms.ObjectMessage.
>>>
>>> ObjectMessage says:
>>>
>>> "
>>> An |ObjectMessage| object is used to send a message that contains a
>>> serializable object in the Java programming language ("Java object"). It
>>> inherits from the |Message| interface and adds a body containing a single
>>> reference to an object. Only |Serializable| Java objects can be used.
>>>
>>> If a collection of Java objects must be sent, one of the |Collection|
>>> classes provided since JDK 1.2 can be used.
>>>
>>> "
>>> The last paragraph is particularly interesting and is suggesting to me
>>> that
>>> this is exactly what is being implicitly suggested by Sun/Oracle as the
>>> preferred way of passing Collections of various sorts via JMS.
>>>
>>>
>>> Now to be fair things were perhaps more awkward in older versions of Qpid
>>> when the AMQP Content-Type wasn't getting exposed in JMS, but even
>>> without
>>> being able to use the Content-Type to avoid speculating casting and
>>> instanceof it still seems preferable. The Content-Type however can add
>>> value
>>> and make the whole thing completely consistent and well specified.
>>>
>>>
>>>
>>> Sorry that this has gone on somewhat, and I apologise for not
>>> contributing
>>> these thoughts when Rajith originally mentioned this (in retrospect it
>>> would
>>> probably have saved me quite some work).
>>>
>>> I hope that I've managed to convince the community that:
>>> a) javax.jms.ObjectMessage is the "one true" JMS specification compliant
>>> way
>>> of exposing amqp/map and amqp/list
>>> b) that there's not a huge gulf between "developers" and "users" and some
>>> of
>>> the choices can have big impacts particularly where "messing with
>>> interfaces" in a not massively well controlled manner is concerned.
>>>
>>> Food for thought???
>>>
>>> I'll make a start getting the QMF2 stuff working with the Qpid 0.20
>>> changes.
>>> Now that I know what I'm up against it's not especially difficult, but
>>> Lists
>>> are used in a few places so I'll probably spend a bit of time trying to
>>> make
>>> sure I've covered it all off and trying to ensure I've abstracted
>>> sufficiently from the underlying JMS Message type so that it won't be too
>>> hard to accommodate ObjectMessage if (when???) things move to that.
>>>
>>>
>>> And Rajith, if any of the stuff above comes across as me having a go at
>>> you
>>> it's *really* not my intention. I hope it doesn't come across like that,
>>> but
>>> emails can come across in ways not intended so I want to make that clear
>>> up
>>> front! I really should have put all of this stuff in a response to your
>>> post, I'm afraid I was just trying to keep focus on my GUI. A flawed
>>> decision on my part as it turns out :-D
>>>
>>> I'll keep you posted.
>>> Frase
>>>
>>>
>>> On 26/01/13 11:32, Fraser Adams wrote:
>>>>
>>>> Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on
>>>> Java.
>>>>
>>>> I've built the main qpid-all.jar and pointed my CLASSPATH at it and
>>>> unfortunately "fings is well broke, innit?" :-(
>>>>
>>>> It's lower level than the GUI stuff as none of the QMF2 stuff is working
>>>> and my QpidConfig port reports "No broker QmfConsoleData returned". My
>>>> initial suspicion is still that somebody has messed around with how AMQP
>>>> list messages are deserialised in Java, but I'll need to dig around a
>>>> bit
>>>> :-(
>>>>
>>>> On a more minor (and I'd assume unrelated) note I see the following on
>>>> every Java Client I've fired up so far:
>>>>
>>>> log4j:WARN No appenders could be found for logger
>>>> (org.apache.qpid.jndi.PropertiesFileInitialContextFactory).
>>>> log4j:WARN Please initialize the log4j system properly.
>>>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
>>>> more info.
>>>>
>>>>
>>>> Odd that it's just that one class
>>>>
>>>> I haven't built the C++ broker/client yet and the Java glitch seems to
>>>> concur with what Gordon saw last week (it looks like a change between
>>>> 0.18
>>>> and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker things
>>>> worked fine) so Java looks like the place to go digging.
>>>>
>>>> I'll keep you posted.
>>>>
>>>> Regards,
>>>> Frase.
>>>>
>>>>
>>>> On 23/01/13 15:30, Justin Ross wrote:
>>>>>
>>>>> The Apache Qpid community is pleased to announce the immediate
>>>>> availability of Apache Qpid 0.20.
>>>>>
>>>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>>>>> messaging solution which implements the Advanced Message Queuing
>>>>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>>>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>>>>> Ruby, and Perl.
>>>>>
>>>>> Qpid 0.20 is available from our website:
>>>>>
>>>>>        http://qpid.apache.org/download.html
>>>>>
>>>>> The 0.20 release includes many bug fixes and improvements.  We
>>>>> recommend that all users upgrade.  A comprehensive list of changes in
>>>>> the 0.20 release is available here:
>>>>>
>>>>>        http://qpid.apache.org/release_notes_0.20.html
>>>>>
>>>>> Thanks to all the users and contributors who have helped to improve
>>>>> Apache Qpid.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Rajith,
Yeah I realise in retrospect that it was discussed, I guess that my 
point is that it was only really flagged the once on the User mailing 
list and it passed my by largely as I was looking at other things. 
That's why I was using it as an example to back up Gordon's comment 
about unifying communication on the user and development list.

 From your comment below are you saying that this is exposed in a choice 
of three forms. It appeared to me as an instanceof MapMessage - how 
would I get it to behave as say a org.apache.qpid.jms.ListMessage? is 
there a config option or can I just cast it?

I don't suppose that you happened to make 
org.apache.qpid.jms.ListMessage implement java.util.List as well as 
javax.jms.Message?? :-) You say "it provides methods like the ones in 
java.util.List " but does it actually implement that interface?

Re "for the client to provide out of the box support instead of 
receiving as bytes messages and having to decode the payload themselves. 
". I've got sympathy with this for sure - I guess I was just bitten by 
the change and also as I've stated my personal view is that the correct 
approach is to use ObjectMessage. I'm not sure I'm winning that argument 
with yourself and Gordon, but I will keep banging on about it :-) I'd be 
interested to know what others think about this. As I said in my reply 
to Gordon a combination of List/Map in ObjectMessage plus exposing AMQP 
Content-Type will a) maximise consistency between JMS and 
qpid::messaging and b) keep within the JMS spec. Both of these are IMHO 
a really good thing.

Regards,
Frase.


On 29/01/13 16:27, Rajith Attapattu wrote:
> Hey Fraser,
>
> The patch was extensively discussed here https://reviews.apache.org/r/6816/
> We expose the List message using
> 1. Map Message
> 2. Stream Message
> 3. org.apache.qpid.jms.ListMessage
>
> I personally don't like the Map Message approach (see my comments on
> the above review request).
> I also think it's hideous.
>
> But you might like the ListMessage interface as it provides methods
> like the ones in java.util.List
>
> The point of adding list message support is for the client to provide
> out of the box support instead of receiving as bytes messages and
> having to decode the payload themselves.
>
> Regards,
>
> Rajith
>
> On Sat, Jan 26, 2013 at 10:43 AM, Fraser Adams
> <fr...@blueyonder.co.uk> wrote:
>> As a follow up to my posting below.
>>
>> QMF2 is indeed broken by Java changes in Qpid 0.20 and my hunch around
>> somebody messing with how Content-Type amqp/list is encoded and decoded does
>> indeed look to be "the smoking gun".
>>
>> I added some debug code to my getObjects() and I was hitherto receiving a
>> BytesMessage, which did need some decoding to retrieve the List, but now it
>> is receiving a MapMessage.
>>
>> I've only started looking, but doing:
>>
>> MapMessage m = (MapMessage)response;
>> for (Enumeration e = m.getMapNames() ; e.hasMoreElements() ;)
>> {
>>      String key = (String)e.nextElement();
>> System.out.println("key = " + key);
>> }
>>
>> indicates (for the "broker" object) "key = 0"
>>
>> Which is suggesting that Lists now seem to be encoded in MapMessages with
>> keys that are indices :'( .
>>
>>
>>
>> To be fair Rajith Attapattu did post on this subject at the end of August:
>>
>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>>
>> and perhaps I *should* have taken more notice, however it was a single
>> posting and pretty inconclusive, so I don't thing that it was unreasonable
>> for me to park it in "things to look at once the QMF stuff is released"
>> given where I was trying to focus my spare time.
>>
>>
>> IMHO this is *exactly* the sort of thing that acts as a "/quod erat
>> demonstrandum/" to Gordon Sim's posting on "mailing lists and fragmented
>> communication", 'cause I'd have got a *whole lot more* animated about the
>> subject if I'd have thought that this stuff was going to actually make it in
>> to a release (see below!!).....
>>
>> Have I just missed where the release notes communicated this, or is this a
>> change that hasn't been communicated to "users" (aside from Rajith's
>> posting)??
>>
>>
>>
>> I have to say that IMHO whilst the BytesMessage stuff (and the associated
>> decoding) "wasn't exactly ideal" I think that the way MapMessage has been
>> used here using String keys as indices feels pretty hideous too :-(
>>
>> There was some talk too in Rajith's post around "Make the list message
>> accessible via the MapMessage and StreamMessage interfaces" I'm not sure if
>> this has been done, but TBH I'm not sure that I like StreamMessage any
>> better!!
>>
>>
>>
>> At the risk of coming over a bit anally retentive.......Here's what I should
>> have taken the time to respond to
>> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>> with:
>>
>>
>> I don't actually like MapMessage a whole lot more than any of the above. I
>> think that even for exposing amqp/map its use is flawed for (at least) two
>> reasons:
>> 1) MapMessage is frankly a hideous interface that should have been kicked
>> into touch years ago by Sun. The particular axe I've got to grind with it is
>> that there's this thing called java.util.Map which has been around since
>> Java 1.2, so it's spectacularly unhelpful to have a different interface for
>> Maps transported via JMS. Among other things It really bugs me having to use
>> Enumerations and not being able to use foreach.
>>
>> It's even more irksome becase QMF often comprises Maps of Maps, so the top
>> level Map ends up being a MapMessage and the rest end up being
>> java.util.Map. It's not at all elegant and frankly I ended up writing a
>> "getMap(final Message message)" method that populates a java.util.Map with
>> the messageProperties and Map values so I'd get at least some consistency.
>>
>> 2) Possibly the main reason using MapMessage is flawed though is because the
>> JMS Spec says:
>> "A |MapMessage| object is used to send a set of name-value pairs. The names
>> are |String| objects, and the values are *primitive data types in the Java
>> programming language*", that's right "primitive data types". To be fair it
>> then goes on to include byte[] in the list and it *does* include a
>> getObject() and setObject(), but the JavaDoc explicitly says "This method
>> works only for the objectified primitive object types (|Integer|, |Double|,
>> |Long| ...), |String| objects, and byte arrays. ".
>>
>>
>> So the bottom line is then that encoding java.util.Map and java.util.List
>> into javax.jms.MapMessage (which are clearly necessary for QMF plus a whole
>> load of other things) *explicitly* breaks the JMS specification (as well as
>> having a really hideous interface).
>>
>> As for StreamMessage that says:
>> "A |StreamMessage| object is used to send a stream of primitive types in the
>> Java programming language" and the writeObject() method JavaDoc says "This
>> method works only for the objectified primitive object types (|Integer|,
>> |Double|, |Long| ...), |String| objects, and byte arrays. ". So again
>> explicitly primitive types.
>>
>>
>> I've said the following a couple of times on the Qpid Users mailing list,
>> but nobody has yet bitten, hopefully this issue might start the discussion
>> again....
>>
>> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a way
>> that doesn't break the JMS specification is to use javax.jms.ObjectMessage.
>>
>> ObjectMessage says:
>>
>> "
>> An |ObjectMessage| object is used to send a message that contains a
>> serializable object in the Java programming language ("Java object"). It
>> inherits from the |Message| interface and adds a body containing a single
>> reference to an object. Only |Serializable| Java objects can be used.
>>
>> If a collection of Java objects must be sent, one of the |Collection|
>> classes provided since JDK 1.2 can be used.
>>
>> "
>> The last paragraph is particularly interesting and is suggesting to me that
>> this is exactly what is being implicitly suggested by Sun/Oracle as the
>> preferred way of passing Collections of various sorts via JMS.
>>
>>
>> Now to be fair things were perhaps more awkward in older versions of Qpid
>> when the AMQP Content-Type wasn't getting exposed in JMS, but even without
>> being able to use the Content-Type to avoid speculating casting and
>> instanceof it still seems preferable. The Content-Type however can add value
>> and make the whole thing completely consistent and well specified.
>>
>>
>>
>> Sorry that this has gone on somewhat, and I apologise for not contributing
>> these thoughts when Rajith originally mentioned this (in retrospect it would
>> probably have saved me quite some work).
>>
>> I hope that I've managed to convince the community that:
>> a) javax.jms.ObjectMessage is the "one true" JMS specification compliant way
>> of exposing amqp/map and amqp/list
>> b) that there's not a huge gulf between "developers" and "users" and some of
>> the choices can have big impacts particularly where "messing with
>> interfaces" in a not massively well controlled manner is concerned.
>>
>> Food for thought???
>>
>> I'll make a start getting the QMF2 stuff working with the Qpid 0.20 changes.
>> Now that I know what I'm up against it's not especially difficult, but Lists
>> are used in a few places so I'll probably spend a bit of time trying to make
>> sure I've covered it all off and trying to ensure I've abstracted
>> sufficiently from the underlying JMS Message type so that it won't be too
>> hard to accommodate ObjectMessage if (when???) things move to that.
>>
>>
>> And Rajith, if any of the stuff above comes across as me having a go at you
>> it's *really* not my intention. I hope it doesn't come across like that, but
>> emails can come across in ways not intended so I want to make that clear up
>> front! I really should have put all of this stuff in a response to your
>> post, I'm afraid I was just trying to keep focus on my GUI. A flawed
>> decision on my part as it turns out :-D
>>
>> I'll keep you posted.
>> Frase
>>
>>
>> On 26/01/13 11:32, Fraser Adams wrote:
>>> Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on Java.
>>>
>>> I've built the main qpid-all.jar and pointed my CLASSPATH at it and
>>> unfortunately "fings is well broke, innit?" :-(
>>>
>>> It's lower level than the GUI stuff as none of the QMF2 stuff is working
>>> and my QpidConfig port reports "No broker QmfConsoleData returned". My
>>> initial suspicion is still that somebody has messed around with how AMQP
>>> list messages are deserialised in Java, but I'll need to dig around a bit
>>> :-(
>>>
>>> On a more minor (and I'd assume unrelated) note I see the following on
>>> every Java Client I've fired up so far:
>>>
>>> log4j:WARN No appenders could be found for logger
>>> (org.apache.qpid.jndi.PropertiesFileInitialContextFactory).
>>> log4j:WARN Please initialize the log4j system properly.
>>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
>>> more info.
>>>
>>>
>>> Odd that it's just that one class
>>>
>>> I haven't built the C++ broker/client yet and the Java glitch seems to
>>> concur with what Gordon saw last week (it looks like a change between 0.18
>>> and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker things
>>> worked fine) so Java looks like the place to go digging.
>>>
>>> I'll keep you posted.
>>>
>>> Regards,
>>> Frase.
>>>
>>>
>>> On 23/01/13 15:30, Justin Ross wrote:
>>>> The Apache Qpid community is pleased to announce the immediate
>>>> availability of Apache Qpid 0.20.
>>>>
>>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>>>> messaging solution which implements the Advanced Message Queuing
>>>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>>>> Ruby, and Perl.
>>>>
>>>> Qpid 0.20 is available from our website:
>>>>
>>>>        http://qpid.apache.org/download.html
>>>>
>>>> The 0.20 release includes many bug fixes and improvements.  We
>>>> recommend that all users upgrade.  A comprehensive list of changes in
>>>> the 0.20 release is available here:
>>>>
>>>>        http://qpid.apache.org/release_notes_0.20.html
>>>>
>>>> Thanks to all the users and contributors who have helped to improve
>>>> Apache Qpid.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Rajith Attapattu <ra...@gmail.com>.
Hey Fraser,

The patch was extensively discussed here https://reviews.apache.org/r/6816/
We expose the List message using
1. Map Message
2. Stream Message
3. org.apache.qpid.jms.ListMessage

I personally don't like the Map Message approach (see my comments on
the above review request).
I also think it's hideous.

But you might like the ListMessage interface as it provides methods
like the ones in java.util.List

The point of adding list message support is for the client to provide
out of the box support instead of receiving as bytes messages and
having to decode the payload themselves.

Regards,

Rajith

On Sat, Jan 26, 2013 at 10:43 AM, Fraser Adams
<fr...@blueyonder.co.uk> wrote:
> As a follow up to my posting below.
>
> QMF2 is indeed broken by Java changes in Qpid 0.20 and my hunch around
> somebody messing with how Content-Type amqp/list is encoded and decoded does
> indeed look to be "the smoking gun".
>
> I added some debug code to my getObjects() and I was hitherto receiving a
> BytesMessage, which did need some decoding to retrieve the List, but now it
> is receiving a MapMessage.
>
> I've only started looking, but doing:
>
> MapMessage m = (MapMessage)response;
> for (Enumeration e = m.getMapNames() ; e.hasMoreElements() ;)
> {
>     String key = (String)e.nextElement();
> System.out.println("key = " + key);
> }
>
> indicates (for the "broker" object) "key = 0"
>
> Which is suggesting that Lists now seem to be encoded in MapMessages with
> keys that are indices :'( .
>
>
>
> To be fair Rajith Attapattu did post on this subject at the end of August:
>
> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>
> and perhaps I *should* have taken more notice, however it was a single
> posting and pretty inconclusive, so I don't thing that it was unreasonable
> for me to park it in "things to look at once the QMF stuff is released"
> given where I was trying to focus my spare time.
>
>
> IMHO this is *exactly* the sort of thing that acts as a "/quod erat
> demonstrandum/" to Gordon Sim's posting on "mailing lists and fragmented
> communication", 'cause I'd have got a *whole lot more* animated about the
> subject if I'd have thought that this stuff was going to actually make it in
> to a release (see below!!).....
>
> Have I just missed where the release notes communicated this, or is this a
> change that hasn't been communicated to "users" (aside from Rajith's
> posting)??
>
>
>
> I have to say that IMHO whilst the BytesMessage stuff (and the associated
> decoding) "wasn't exactly ideal" I think that the way MapMessage has been
> used here using String keys as indices feels pretty hideous too :-(
>
> There was some talk too in Rajith's post around "Make the list message
> accessible via the MapMessage and StreamMessage interfaces" I'm not sure if
> this has been done, but TBH I'm not sure that I like StreamMessage any
> better!!
>
>
>
> At the risk of coming over a bit anally retentive.......Here's what I should
> have taken the time to respond to
> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
> with:
>
>
> I don't actually like MapMessage a whole lot more than any of the above. I
> think that even for exposing amqp/map its use is flawed for (at least) two
> reasons:
> 1) MapMessage is frankly a hideous interface that should have been kicked
> into touch years ago by Sun. The particular axe I've got to grind with it is
> that there's this thing called java.util.Map which has been around since
> Java 1.2, so it's spectacularly unhelpful to have a different interface for
> Maps transported via JMS. Among other things It really bugs me having to use
> Enumerations and not being able to use foreach.
>
> It's even more irksome becase QMF often comprises Maps of Maps, so the top
> level Map ends up being a MapMessage and the rest end up being
> java.util.Map. It's not at all elegant and frankly I ended up writing a
> "getMap(final Message message)" method that populates a java.util.Map with
> the messageProperties and Map values so I'd get at least some consistency.
>
> 2) Possibly the main reason using MapMessage is flawed though is because the
> JMS Spec says:
> "A |MapMessage| object is used to send a set of name-value pairs. The names
> are |String| objects, and the values are *primitive data types in the Java
> programming language*", that's right "primitive data types". To be fair it
> then goes on to include byte[] in the list and it *does* include a
> getObject() and setObject(), but the JavaDoc explicitly says "This method
> works only for the objectified primitive object types (|Integer|, |Double|,
> |Long| ...), |String| objects, and byte arrays. ".
>
>
> So the bottom line is then that encoding java.util.Map and java.util.List
> into javax.jms.MapMessage (which are clearly necessary for QMF plus a whole
> load of other things) *explicitly* breaks the JMS specification (as well as
> having a really hideous interface).
>
> As for StreamMessage that says:
> "A |StreamMessage| object is used to send a stream of primitive types in the
> Java programming language" and the writeObject() method JavaDoc says "This
> method works only for the objectified primitive object types (|Integer|,
> |Double|, |Long| ...), |String| objects, and byte arrays. ". So again
> explicitly primitive types.
>
>
> I've said the following a couple of times on the Qpid Users mailing list,
> but nobody has yet bitten, hopefully this issue might start the discussion
> again....
>
> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a way
> that doesn't break the JMS specification is to use javax.jms.ObjectMessage.
>
> ObjectMessage says:
>
> "
> An |ObjectMessage| object is used to send a message that contains a
> serializable object in the Java programming language ("Java object"). It
> inherits from the |Message| interface and adds a body containing a single
> reference to an object. Only |Serializable| Java objects can be used.
>
> If a collection of Java objects must be sent, one of the |Collection|
> classes provided since JDK 1.2 can be used.
>
> "
> The last paragraph is particularly interesting and is suggesting to me that
> this is exactly what is being implicitly suggested by Sun/Oracle as the
> preferred way of passing Collections of various sorts via JMS.
>
>
> Now to be fair things were perhaps more awkward in older versions of Qpid
> when the AMQP Content-Type wasn't getting exposed in JMS, but even without
> being able to use the Content-Type to avoid speculating casting and
> instanceof it still seems preferable. The Content-Type however can add value
> and make the whole thing completely consistent and well specified.
>
>
>
> Sorry that this has gone on somewhat, and I apologise for not contributing
> these thoughts when Rajith originally mentioned this (in retrospect it would
> probably have saved me quite some work).
>
> I hope that I've managed to convince the community that:
> a) javax.jms.ObjectMessage is the "one true" JMS specification compliant way
> of exposing amqp/map and amqp/list
> b) that there's not a huge gulf between "developers" and "users" and some of
> the choices can have big impacts particularly where "messing with
> interfaces" in a not massively well controlled manner is concerned.
>
> Food for thought???
>
> I'll make a start getting the QMF2 stuff working with the Qpid 0.20 changes.
> Now that I know what I'm up against it's not especially difficult, but Lists
> are used in a few places so I'll probably spend a bit of time trying to make
> sure I've covered it all off and trying to ensure I've abstracted
> sufficiently from the underlying JMS Message type so that it won't be too
> hard to accommodate ObjectMessage if (when???) things move to that.
>
>
> And Rajith, if any of the stuff above comes across as me having a go at you
> it's *really* not my intention. I hope it doesn't come across like that, but
> emails can come across in ways not intended so I want to make that clear up
> front! I really should have put all of this stuff in a response to your
> post, I'm afraid I was just trying to keep focus on my GUI. A flawed
> decision on my part as it turns out :-D
>
> I'll keep you posted.
> Frase
>
>
> On 26/01/13 11:32, Fraser Adams wrote:
>>
>> Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on Java.
>>
>> I've built the main qpid-all.jar and pointed my CLASSPATH at it and
>> unfortunately "fings is well broke, innit?" :-(
>>
>> It's lower level than the GUI stuff as none of the QMF2 stuff is working
>> and my QpidConfig port reports "No broker QmfConsoleData returned". My
>> initial suspicion is still that somebody has messed around with how AMQP
>> list messages are deserialised in Java, but I'll need to dig around a bit
>> :-(
>>
>> On a more minor (and I'd assume unrelated) note I see the following on
>> every Java Client I've fired up so far:
>>
>> log4j:WARN No appenders could be found for logger
>> (org.apache.qpid.jndi.PropertiesFileInitialContextFactory).
>> log4j:WARN Please initialize the log4j system properly.
>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
>> more info.
>>
>>
>> Odd that it's just that one class
>>
>> I haven't built the C++ broker/client yet and the Java glitch seems to
>> concur with what Gordon saw last week (it looks like a change between 0.18
>> and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker things
>> worked fine) so Java looks like the place to go digging.
>>
>> I'll keep you posted.
>>
>> Regards,
>> Frase.
>>
>>
>> On 23/01/13 15:30, Justin Ross wrote:
>>>
>>> The Apache Qpid community is pleased to announce the immediate
>>> availability of Apache Qpid 0.20.
>>>
>>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>>> messaging solution which implements the Advanced Message Queuing
>>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>>> Ruby, and Perl.
>>>
>>> Qpid 0.20 is available from our website:
>>>
>>>       http://qpid.apache.org/download.html
>>>
>>> The 0.20 release includes many bug fixes and improvements.  We
>>> recommend that all users upgrade.  A comprehensive list of changes in
>>> the 0.20 release is available here:
>>>
>>>       http://qpid.apache.org/release_notes_0.20.html
>>>
>>> Thanks to all the users and contributors who have helped to improve
>>> Apache Qpid.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Gordon Sim <gs...@redhat.com>.
On 01/29/2013 06:32 PM, Fraser Adams wrote:
>from a perspective of decoding
> it's not too hard to write defensive code to be able to handle a
> reasonable set of variations, that's what I did at in my code where I
> checked the Content-Type so was able to figure out that the MapMessage
> that I was getting was really a list.

I feel the library can also help here, that's the idea behind allowing 
the message to be treated as a variety of different types. Arguably 
another way you should be able to treat the message is as a BytesMessage 
in which case you would get the raw encoded bytes and had that been 
supported your application would have continued to work as before.

> On the encoding side that's where
> it'd be good for the runtime to be able to be tolerant so if I send a
> BytesMessage with amqp/list it behaves as it did

I agree, that should be the case.

>, or a MapMessage with
> amqp/list it behaves as 0.20 and (hopefully) in the future if I send and
> ObjectMessage containing a List with a Content-Type of amqp/list then
> that would work too.

I agree.

> I think that exposing the AMQP Content-Type more satisfactorily is very
> much our friend from the perspective of interoperability.

I agree.

> I still assert that ObjectMessage is the only way to expose amqp/map and
> amqp/list and properly conform to the spec.

I don't think it is or should be the _only_ way. I accept it could be 
one useful way of doing so. If I send a simple map, receiving it from 
JMS as a MapMessage seems reasonable. Being able to treat it as some 
other message type may also be reasonable.

> Just because we might want
> to introduce a constraint that only Maps and Lists (and other types with
> an AMQP serialisation) are supported here and not arbitrary Java objects
> isn't a huge constraint (especially if it's documented).

I think such constraints are perfectly acceptable in conjunction with 
some other way (e.g. content-type property) for indicating the desired 
encoding. That way, if you want it encoded in AMQP's type system there 
may be some restrictions on the object in question, otherwise 
serialization is used as expected.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Gordon,
It's true that ObjectMessage allows for the possibility of any 
serializable object, what I'm talking about here is using that to 
facilitate java.util.Map to be sent as an amqp/map and java.util.List to 
be sent as an amqp/list. To be fair I don't think that this feels any 
different than any other mapping e.g. for ints, longs etc. and frankly 
as we've previously discussed we've also got awkwardness with String 
interoperability (String, byte[] depending on whether utf8 is specified 
in C++ clients).

So whilst I agree to some extent that there's a potential for 
misunderstanding I don't see that as any worse than saying we're using 
MapMessage to expose amqp/map. At the very least at least it will 
conform to the JMS spec because java.util.Map and java.util.List are 
both serializable. And as I say there's implicit guidance in the JavaDoc 
that ObjectMessage is the way to go for transporting collections.

To be honest better exposing the AMQP Content-Type would help with any 
ambiguity, for example a pattern of explicitly setting the Content-Type 
of amqp/list and using a java.util.List as the payload of a 
javax.jms.ObjectMessage - and similarly for amqp/map and java.util.Map 
is IMHO exactly analogous to what one would do in qpid::messaging with 
the Content Type and Variant::List and Variant::Map. I really like the 
idea of consistent usage patterns between qpid::messaging and JMS. The 
APIs are already extremely similar so promoting this sort of pattern 
seems like a good idea in my book.

Re "is not driven from a love of those interfaces, but from the fact 
that they are already defined and there may be applications using them 
or developers used to working with them. " I feel a sense of irony 
coming on here given my experiences over the weekend :-D

I've got some sympathy with this view - from a perspective of decoding 
it's not too hard to write defensive code to be able to handle a 
reasonable set of variations, that's what I did at in my code where I 
checked the Content-Type so was able to figure out that the MapMessage 
that I was getting was really a list. On the encoding side that's where 
it'd be good for the runtime to be able to be tolerant so if I send a 
BytesMessage with amqp/list it behaves as it did, or a MapMessage with 
amqp/list it behaves as 0.20 and (hopefully) in the future if I send and 
ObjectMessage containing a List with a Content-Type of amqp/list then 
that would work too.

I think that exposing the AMQP Content-Type more satisfactorily is very 
much our friend from the perspective of interoperability.

I still assert that ObjectMessage is the only way to expose amqp/map and 
amqp/list and properly conform to the spec. Just because we might want 
to introduce a constraint that only Maps and Lists (and other types with 
an AMQP serialisation) are supported here and not arbitrary Java objects 
isn't a huge constraint (especially if it's documented). And still feels 
IMHO ultimately the most consistent model for passing Collections.

Frase.



On 29/01/13 17:34, Gordon Sim wrote:
> On 01/26/2013 03:43 PM, Fraser Adams wrote:
>> I've said the following a couple of times on the Qpid Users mailing
>> list, but nobody has yet bitten, hopefully this issue might start the
>> discussion again....
>>
>> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a
>> way that doesn't break the JMS specification is to use
>> javax.jms.ObjectMessage.
>
> My concern, at least on the sending side, is that people expect java 
> serialization to be used with such messages and therefore expect to be 
> able to use arbitrary java objects with it (as well as relying on e.g. 
> custom readObject()/writeObject()/readExternal()/writeExternal() 
> methods).
>
> While I think that an AMQP encoding for general objects is an 
> interesting avenue to consider[1], its a larger problem than simply 
> handling (potentially recursive) maps and lists of primitive types.
>
> The use of MapMessage and StreamMessage is not driven from a love of 
> those interfaces, but from the fact that they are already defined and 
> there may be applications using them or developers used to working 
> with them.
>
> It is true we don't enforce that lists/maps are non-recursive and that 
> is strictly violating the standard. That fact is noted in the 
> documentation. It would probably be nice to have a way to enable 
> strict compliance as well. It is certainly an issue for QMF messages, 
> which do contain nested lists and maps, but it might not be for other 
> uses.
>
> Likewise however encoding ObjectMessages as an amqp/map rather than 
> using serialization to generate the sequence of bytes might be 
> considered a violation of the specification also.
>
> What we have is certainly not perfect. The JMS API itself is not 
> perfect here.
>
> The idea was to allow AMQP encoded data to be accessed via a variety 
> of interfaces so you can pick the one you prefer. Extending the 
> current options such that a map or list encoded message could also be 
> accessed as an ObjectMessage seems like a reasonable enhancement to me.
>
> The sending side has the added issue of needing to infer the desired 
> encoding in some way. If you allow different encodings for a 
> particular Message type then you need some other explicit way to 
> choose between them.
>
> --Gordon.
>
> [1] AMQP 1.0 provides annotations that could be used to indicate class 
> in a standard way.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Gordon Sim <gs...@redhat.com>.
On 01/26/2013 03:43 PM, Fraser Adams wrote:
> I've said the following a couple of times on the Qpid Users mailing
> list, but nobody has yet bitten, hopefully this issue might start the
> discussion again....
>
> IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a
> way that doesn't break the JMS specification is to use
> javax.jms.ObjectMessage.

My concern, at least on the sending side, is that people expect java 
serialization to be used with such messages and therefore expect to be 
able to use arbitrary java objects with it (as well as relying on e.g. 
custom readObject()/writeObject()/readExternal()/writeExternal() methods).

While I think that an AMQP encoding for general objects is an 
interesting avenue to consider[1], its a larger problem than simply 
handling (potentially recursive) maps and lists of primitive types.

The use of MapMessage and StreamMessage is not driven from a love of 
those interfaces, but from the fact that they are already defined and 
there may be applications using them or developers used to working with 
them.

It is true we don't enforce that lists/maps are non-recursive and that 
is strictly violating the standard. That fact is noted in the 
documentation. It would probably be nice to have a way to enable strict 
compliance as well. It is certainly an issue for QMF messages, which do 
contain nested lists and maps, but it might not be for other uses.

Likewise however encoding ObjectMessages as an amqp/map rather than 
using serialization to generate the sequence of bytes might be 
considered a violation of the specification also.

What we have is certainly not perfect. The JMS API itself is not perfect 
here.

The idea was to allow AMQP encoded data to be accessed via a variety of 
interfaces so you can pick the one you prefer. Extending the current 
options such that a map or list encoded message could also be accessed 
as an ObjectMessage seems like a reasonable enhancement to me.

The sending side has the added issue of needing to infer the desired 
encoding in some way. If you allow different encodings for a particular 
Message type then you need some other explicit way to choose between them.

--Gordon.

[1] AMQP 1.0 provides annotations that could be used to indicate class 
in a standard way.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

JMS List support & QMF2 - was Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
As a follow up to my posting below.

QMF2 is indeed broken by Java changes in Qpid 0.20 and my hunch around 
somebody messing with how Content-Type amqp/list is encoded and decoded 
does indeed look to be "the smoking gun".

I added some debug code to my getObjects() and I was hitherto receiving 
a BytesMessage, which did need some decoding to retrieve the List, but 
now it is receiving a MapMessage.

I've only started looking, but doing:

MapMessage m = (MapMessage)response;
for (Enumeration e = m.getMapNames() ; e.hasMoreElements() ;)
{
     String key = (String)e.nextElement();
System.out.println("key = " + key);
}

indicates (for the "broker" object) "key = 0"

Which is suggesting that Lists now seem to be encoded in MapMessages 
with keys that are indices :'( .



To be fair Rajith Attapattu did post on this subject at the end of August:

http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html

and perhaps I *should* have taken more notice, however it was a single 
posting and pretty inconclusive, so I don't thing that it was 
unreasonable for me to park it in "things to look at once the QMF stuff 
is released" given where I was trying to focus my spare time.


IMHO this is *exactly* the sort of thing that acts as a "/quod erat 
demonstrandum/" to Gordon Sim's posting on "mailing lists and fragmented 
communication", 'cause I'd have got a *whole lot more* animated about 
the subject if I'd have thought that this stuff was going to actually 
make it in to a release (see below!!).....

Have I just missed where the release notes communicated this, or is this 
a change that hasn't been communicated to "users" (aside from Rajith's 
posting)??



I have to say that IMHO whilst the BytesMessage stuff (and the 
associated decoding) "wasn't exactly ideal" I think that the way 
MapMessage has been used here using String keys as indices feels pretty 
hideous too :-(

There was some talk too in Rajith's post around "Make the list message 
accessible via the MapMessage and StreamMessage interfaces" I'm not sure 
if this has been done, but TBH I'm not sure that I like StreamMessage 
any better!!



At the risk of coming over a bit anally retentive.......Here's what I 
should have taken the time to respond to 
http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html 
with:


I don't actually like MapMessage a whole lot more than any of the above. 
I think that even for exposing amqp/map its use is flawed for (at least) 
two reasons:
1) MapMessage is frankly a hideous interface that should have been 
kicked into touch years ago by Sun. The particular axe I've got to grind 
with it is that there's this thing called java.util.Map which has been 
around since Java 1.2, so it's spectacularly unhelpful to have a 
different interface for Maps transported via JMS. Among other things It 
really bugs me having to use Enumerations and not being able to use foreach.

It's even more irksome becase QMF often comprises Maps of Maps, so the 
top level Map ends up being a MapMessage and the rest end up being 
java.util.Map. It's not at all elegant and frankly I ended up writing a 
"getMap(final Message message)" method that populates a java.util.Map 
with the messageProperties and Map values so I'd get at least some 
consistency.

2) Possibly the main reason using MapMessage is flawed though is because 
the JMS Spec says:
"A |MapMessage| object is used to send a set of name-value pairs. The 
names are |String| objects, and the values are *primitive data types in 
the Java programming language*", that's right "primitive data types". To 
be fair it then goes on to include byte[] in the list and it *does* 
include a getObject() and setObject(), but the JavaDoc explicitly says 
"This method works only for the objectified primitive object types 
(|Integer|, |Double|, |Long| ...), |String| objects, and byte arrays. ".


So the bottom line is then that encoding java.util.Map and 
java.util.List into javax.jms.MapMessage (which are clearly necessary 
for QMF plus a whole load of other things) *explicitly* breaks the JMS 
specification (as well as having a really hideous interface).

As for StreamMessage that says:
"A |StreamMessage| object is used to send a stream of primitive types in 
the Java programming language" and the writeObject() method JavaDoc says 
"This method works only for the objectified primitive object types 
(|Integer|, |Double|, |Long| ...), |String| objects, and byte arrays. ". 
So again explicitly primitive types.


I've said the following a couple of times on the Qpid Users mailing 
list, but nobody has yet bitten, hopefully this issue might start the 
discussion again....

IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a 
way that doesn't break the JMS specification is to use 
javax.jms.ObjectMessage.

ObjectMessage says:

"
An |ObjectMessage| object is used to send a message that contains a 
serializable object in the Java programming language ("Java object"). It 
inherits from the |Message| interface and adds a body containing a 
single reference to an object. Only |Serializable| Java objects can be 
used.

If a collection of Java objects must be sent, one of the |Collection| 
classes provided since JDK 1.2 can be used.

"
The last paragraph is particularly interesting and is suggesting to me 
that this is exactly what is being implicitly suggested by Sun/Oracle as 
the preferred way of passing Collections of various sorts via JMS.


Now to be fair things were perhaps more awkward in older versions of 
Qpid when the AMQP Content-Type wasn't getting exposed in JMS, but even 
without being able to use the Content-Type to avoid speculating casting 
and instanceof it still seems preferable. The Content-Type however can 
add value and make the whole thing completely consistent and well 
specified.



Sorry that this has gone on somewhat, and I apologise for not 
contributing these thoughts when Rajith originally mentioned this (in 
retrospect it would probably have saved me quite some work).

I hope that I've managed to convince the community that:
a) javax.jms.ObjectMessage is the "one true" JMS specification compliant 
way of exposing amqp/map and amqp/list
b) that there's not a huge gulf between "developers" and "users" and 
some of the choices can have big impacts particularly where "messing 
with interfaces" in a not massively well controlled manner is concerned.

Food for thought???

I'll make a start getting the QMF2 stuff working with the Qpid 0.20 
changes. Now that I know what I'm up against it's not especially 
difficult, but Lists are used in a few places so I'll probably spend a 
bit of time trying to make sure I've covered it all off and trying to 
ensure I've abstracted sufficiently from the underlying JMS Message type 
so that it won't be too hard to accommodate ObjectMessage if (when???) 
things move to that.


And Rajith, if any of the stuff above comes across as me having a go at 
you it's *really* not my intention. I hope it doesn't come across like 
that, but emails can come across in ways not intended so I want to make 
that clear up front! I really should have put all of this stuff in a 
response to your post, I'm afraid I was just trying to keep focus on my 
GUI. A flawed decision on my part as it turns out :-D

I'll keep you posted.
Frase


On 26/01/13 11:32, Fraser Adams wrote:
> Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on Java.
>
> I've built the main qpid-all.jar and pointed my CLASSPATH at it and 
> unfortunately "fings is well broke, innit?" :-(
>
> It's lower level than the GUI stuff as none of the QMF2 stuff is 
> working and my QpidConfig port reports "No broker QmfConsoleData 
> returned". My initial suspicion is still that somebody has messed 
> around with how AMQP list messages are deserialised in Java, but I'll 
> need to dig around a bit :-(
>
> On a more minor (and I'd assume unrelated) note I see the following on 
> every Java Client I've fired up so far:
>
> log4j:WARN No appenders could be found for logger 
> (org.apache.qpid.jndi.PropertiesFileInitialContextFactory).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig 
> for more info.
>
>
> Odd that it's just that one class
>
> I haven't built the C++ broker/client yet and the Java glitch seems to 
> concur with what Gordon saw last week (it looks like a change between 
> 0.18 and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker 
> things worked fine) so Java looks like the place to go digging.
>
> I'll keep you posted.
>
> Regards,
> Frase.
>
>
> On 23/01/13 15:30, Justin Ross wrote:
>> The Apache Qpid community is pleased to announce the immediate
>> availability of Apache Qpid 0.20.
>>
>> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
>> messaging solution which implements the Advanced Message Queuing
>> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
>> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
>> Ruby, and Perl.
>>
>> Qpid 0.20 is available from our website:
>>
>>       http://qpid.apache.org/download.html
>>
>> The 0.20 release includes many bug fixes and improvements.  We
>> recommend that all users upgrade.  A comprehensive list of changes in
>> the 0.20 release is available here:
>>
>>       http://qpid.apache.org/release_notes_0.20.html
>>
>> Thanks to all the users and contributors who have helped to improve
>> Apache Qpid.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Gripes so far...... I'm afraid it looks like 0.20 has broken QMF on Java.

I've built the main qpid-all.jar and pointed my CLASSPATH at it and 
unfortunately "fings is well broke, innit?" :-(

It's lower level than the GUI stuff as none of the QMF2 stuff is working 
and my QpidConfig port reports "No broker QmfConsoleData returned". My 
initial suspicion is still that somebody has messed around with how AMQP 
list messages are deserialised in Java, but I'll need to dig around a 
bit :-(

On a more minor (and I'd assume unrelated) note I see the following on 
every Java Client I've fired up so far:

log4j:WARN No appenders could be found for logger 
(org.apache.qpid.jndi.PropertiesFileInitialContextFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for 
more info.


Odd that it's just that one class

I haven't built the C++ broker/client yet and the Java glitch seems to 
concur with what Gordon saw last week (it looks like a change between 
0.18 and 0.20 as when he used 0.18 jars and pointed at a 0.20 broker 
things worked fine) so Java looks like the place to go digging.

I'll keep you posted.

Regards,
Frase.


On 23/01/13 15:30, Justin Ross wrote:
> The Apache Qpid community is pleased to announce the immediate
> availability of Apache Qpid 0.20.
>
> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
> messaging solution which implements the Advanced Message Queuing
> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
> Ruby, and Perl.
>
> Qpid 0.20 is available from our website:
>
>       http://qpid.apache.org/download.html
>
> The 0.20 release includes many bug fixes and improvements.  We
> recommend that all users upgrade.  A comprehensive list of changes in
> the 0.20 release is available here:
>
>       http://qpid.apache.org/release_notes_0.20.html
>
> Thanks to all the users and contributors who have helped to improve
> Apache Qpid.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Justin Ross <jr...@apache.org>.
Thanks again, everyone, for improving and testing Qpid, and for using
Qpid to make cool things.  Through your efforts, it has truly improved
tremendously.

Justin

On Wed, Jan 23, 2013 at 10:30 AM, Justin Ross <jr...@apache.org> wrote:
> The Apache Qpid community is pleased to announce the immediate
> availability of Apache Qpid 0.20.
>
> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
> messaging solution which implements the Advanced Message Queuing
> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
> Ruby, and Perl.
>
> Qpid 0.20 is available from our website:
>
>      http://qpid.apache.org/download.html
>
> The 0.20 release includes many bug fixes and improvements.  We
> recommend that all users upgrade.  A comprehensive list of changes in
> the 0.20 release is available here:
>
>      http://qpid.apache.org/release_notes_0.20.html
>
> Thanks to all the users and contributors who have helped to improve
> Apache Qpid.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: [ANNOUNCE] Apache Qpid 0.20 released

Posted by Justin Ross <jr...@apache.org>.
Thanks again, everyone, for improving and testing Qpid, and for using
Qpid to make cool things.  Through your efforts, it has truly improved
tremendously.

Justin

On Wed, Jan 23, 2013 at 10:30 AM, Justin Ross <jr...@apache.org> wrote:
> The Apache Qpid community is pleased to announce the immediate
> availability of Apache Qpid 0.20.
>
> Apache Qpid (http://qpid.apache.org) is a cross-platform enterprise
> messaging solution which implements the Advanced Message Queuing
> Protocol (AMQP, http://www.amqp.org).  It provides brokers written in
> C++ and Java, along with clients for C++, Java JMS, .Net, Python,
> Ruby, and Perl.
>
> Qpid 0.20 is available from our website:
>
>      http://qpid.apache.org/download.html
>
> The 0.20 release includes many bug fixes and improvements.  We
> recommend that all users upgrade.  A comprehensive list of changes in
> the 0.20 release is available here:
>
>      http://qpid.apache.org/release_notes_0.20.html
>
> Thanks to all the users and contributors who have helped to improve
> Apache Qpid.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org