activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Dean (JIRA)" <>
Subject [jira] Updated: (AMQ-2874) Add selector support to amq.js
Date Tue, 14 Sep 2010 19:58:40 GMT


Alex Dean updated AMQ-2874:

    Attachment: add_selector_support_to_amq_js.2.patch

Updated patch changes signature for addListener() in amq.js.
  addListener( id, topic, callback, selector )
  addListener( id, topic, callback, options )

Options can be { selector:"property-name='property-value'" }.  This leaves room for other
options to be added to addListener() in the future without needing to change its signature
again.  I think it also makes the resulting code more readable, since you know right away
that this string is a selector.

> Add selector support to amq.js
> ------------------------------
>                 Key: AMQ-2874
>                 URL:
>             Project: ActiveMQ
>          Issue Type: New Feature
>    Affects Versions: 5.4.0
>         Environment: OSX 10.5.6
>            Reporter: Alex Dean
>         Attachments: add_selector_support_to_amq_js.2.patch, add_selector_support_to_amq_js.patch
> The attached patch adds support for selectors to amq.js and the ajax adapters for jQuery,
Prototype, and Dojo.  Unit tests (and a JavaScript testing framework to run them) are included
for amq.js.  I'm happy to port the tests to another testing framework if you have one already.
 I wasn't able to find anything like that in the current ActiveMQ sources, and this one seems
pretty lightweight.  You can run the tests by pointing your browser to 'activemq-web-demo/src/test/javascript/amq_test.html'
(as a local filesystem reference, no server required).
> I tested the ajax adapters both with and without selectors in the following browsers:
FF 3.5 on WinXP, IE7 on WinXP, FF 3.5 on OSX, Safari 4 on OSX.  The additions of slectors
appears to work as intended.
> Please especially review the test case 'testQueuedMessagesWithoutHeadersAreDeliveredInASinglePost'.
 In this scenario, 5 messages are queued while a current POST is out to the server.  Messages
are send, listen (with selector), send, listen (with selector), send.  The listen messages
must go on their own.  If they were batched, the distinct selectors would be merged together
and (I assume) applied to both listen commands.  The part I'm not sure about is that the messages
are actually delivered in 3 POSTS.  (send, send, send), (listen), (listen).  The 3 outgoing
messages all go in 1 POST, then the 2 listens are sent separately.  The thing I'm not sure
about is that this means the messages are delivered in an order which differs from the order
they were queued in.  I'm not sure if that could pose a problem or not.
> If that is undesired, it would be quite easy to ensure that messages are delivered in
the same order they're queued in.  In the test case I mentioned above, it would just require
that 5 separate POSTs be performed.  Not difficult.
> I'm of course very interested in other feedback on this patch, or on the tests.  I've
not submitted code to this project before, so please let me know what I can do to get this
patch into an acceptable form.  If you'd like me to attempt integrating these JavaScript tests
into Hudson or another CI server, I can take a stab at that as well.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message