RESTEasy MOM has only been used/tested with JBoss MQ on JBoss 4.2.2. It should work with other JMS providers and on other application servers, but you may have to do some tweaking. RESTEasy MOM is deployed as a WAR file. To configure you will have to modify its web.xml file.
By default, RESTEasy MOM will try to lookup and use a ConnectionFactory stored under the JNDI name "java:/ConnectionFactory". You can configure it to look into another JNDI location by setting the context param:
resteasy.mom.connection.factory
When RESTEasy MOM cannot deliver a message it tries to send the message to a dead letter queue. It looks for this in JNDI, by default, under "queue/DLQ". You can configure this setting via
resteasy.mom.dlq.jndi
Every RESTEasy MOM URI path is prefaced with
/queues/{queue-name}
or
/topics/{topic-name}
By default, RESTEasy MOM will try and lookup destinations as follows:
Destination dest = (Destination)jndi.lookup("queue/" + {queue-name});
or
Destination dest = (Destination)jndi.lookup("topic/" + {topic-name});
If you are using JBoss MQ and you have not defined a specific JNDIName for your queue or topic, then this will just work, if not, read further.
You can use the resteasy.mom.queues.jndi or resteasy.mom.topics.jndi web.xml context-params to specify a name/jndiName mapping of the form:
name ':' jndi-name
As many as these as you want separate by a ','. For example:
<context-param> <param-name>resteasy.mom.queues.jndi</param-name> <param-value> queueA : java:comp/env/jms/MyQueue, queueB : jboss/queues/B </param-value> </context-param>
If you cannot obtain JMS ConnectionFactory or destinations from JNDI, then you must write your own RestasyMomBootstrap class. Download the RESTEasy MOM src and checkout the implementation of this class. Its pretty straightforward.
POST /queues/{queue-name}?persistent=[true|false]&priority=[0-9+]&timeToLive=[0-9+]
Response is 204 NO-CONTENT on success. All query parameters optional
POST /queues/{queue-name}/head?wait=[0-9+]
Wait is optional. Defaults to wait forever.
GET /queues/{queue-name}/browser
Returns HTML document with links to message you can view.
Dedicated queues receivers are JMS message consumers attached to a specific session.
PUT /queues/{queue-name}/receivers/{receiver-id}
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /queues/{queue-name}/receivers/{receiver-id}
GET /queues/{queue-name}/receivers/{receiver-id}/head?wait=[0-9+]
DELETE /queues/{queue-name}/receivers/{receiver-id}/head
FYI, this is idempotent still!
POST /queues/{queue-name}/receivers/{reciever-id}/head
You can register a URI to post to when a message is sent to the queue. This registers a MessageListener with the queue. When the message is received, on the server, it send the message to the registered URI.
PUT /queues/{queue-name}/listeners/{listener-id}
You must send a string that is the URI you want to send the message to. The content-type can be anything, "text/plain" or whatever.
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /queues/{queue-name}/receivers/{receiver-id}
POST /topics/{topic-name}?persistent=[true|false]&priority=[0-9+]&timeToLive=[0-9+]
Response is 204 NO-CONTENT on success. All query parameters optional
Dedicated topic receivers are JMS message consumers attached to a specific session.
PUT /topics/{topic-name}/receivers/{receiver-id}
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /topics/{topic-name}/receivers/{receiver-id}
GET /topics/{topic-name}/receivers/{receiver-id}/head?wait=[0-9+]
DELETE /topics/{topic-name}/receivers/{receiver-id}/head
FYI, this is idempotent still!
POST /topics/{topic-name}/receivers/{receiver-id}/head
You can register a URI to post to when a message is sent to this dedicated topic listener. This registers a MessageListener with the queue. When the message is received, on the server, it send the message to the registered URI.
PUT /topics/{topic-name}/listeners/{listener-id}
You must send a string that is the URI you want to send the message to. The content-type can be anything, "text/plain" or whatever.
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /topics/{topic-name}/receivers/{receiver-id}
POST /topics/{topic-name}?persistent=[true|false]&priority=[0-9+]&timeToLive=[0-9+]
Response is 204 NO-CONTENT on success. All query parameters optional
Dedicated topic receivers are JMS message consumers attached to a specific session.
PUT /topics/{topic-name}/durable/receivers/{receiver-id}
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /topics/{topic-name}/durable/receivers/{receiver-id}
GET /topics/{topic-name}/durable/receivers/{receiver-id}/head?wait=[0-9+]
DELETE /topics/{topic-name}/durable/receivers/{receiver-id}/head
FYI, this is idempotent still!
POST /topics/{topic-name}/durable/receivers/{receiver-id}/head
You can register a URI to post to when a message is sent to this dedicated topic listener. This registers a MessageListener with the queue. When the message is received, on the server, it send the message to the registered URI.
PUT /topics/{topic-name}/durable/listeners/{listener-id}
You must send a string that is the URI you want to send the message to. The content-type can be anything, "text/plain" or whatever.
If you pass an ACCEPT header this will create a JMS selector that filters message for only a specific media type. So, if you pass an ACCEPT header of 'application/xml' this receiver will only get message of CONTENT-TYPE 'application/xml'
DELETE /topics/{topic-name}/durable/receivers/{receiver-id}