Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 41 Next »

This docs is for v0.2+

Overview

  1.  Start from v0.2, it is not longer a mandatory to provide a JMS ConnectionFactory. For a single JVM simple usage, you may use the default in-memory, non-persistent ActiveMQ connection factory, or you could configure your JMSProvider in several ways.

Usage

Concepts

  • GroovyJMS Execution Context
    • GroovyJMS mainly provide an execution context that you can use enhanced JMS API and convenient methods, and access to implicit variables
    • GroovyJMS is based on JMS and preserve any JMS concepts and keywords.  You could mix the usage of GroovyJMS API and JMS API in the execution context.
  • JMS Resource - ConnectionFactory, Connection and Session. You could create any of them outside the execution context and pass to the constructor of GroovyJMS, or you could use the implicitly created instances.
    • Refer to the next section about JMS ConnectionFactory
    • Inside the execution context, you could get a copy of the thread-scope connection and session instance. But you cannot set a new connection or session.
    • JMS Resources are used interchangeably when creating lower level JMS Resource
    • GroovyJMS provides high level API that use a single connection and session per thread. Unless you want a fine-grained control over the re-use of Connection and Session, it is not necessary to care about these resources.
  • JMS Destination - Queue, Topic
    • There are two types of JMS destination. GroovyJMS provides high level API to operate on any Queue or Topic, unless you need to get a reference for JMS Destination, you don't need to care about JMS Destinations.
    • Short API are provided for creating JMS Destinations. Similar to JMS Resource, calling subject is interchangable.
    • The return value of topic() and queue() are JMS Topic and Queue respectively. However, in GroovyJMS Execution Context, you could use some operation APIs such as send(), receive() etc. directly on JMS Destination.
  • GroovyJMS API
    • For simple usage, it is the only thing you need to learn. GroovyJMS API uses keywords from JMS API.
      • "send" and "receive" for Queue messages
      • "publish" and "subscribe" for Topic messages
    • You could call the API in two style
      • Message as subject, and sendTo
      • Or use the destination/Message as subject
      • For certain operations, you don't even need a subject
      • API in a spreadsheet [http://www.editgrid.com/publish/html/user/mingfai/24976908/A2:M24]
  • Groovy Messaging Service API
    • GroovyJMS module also provide a Groovy Messaging Service API, that is similar to the Groovy core Sql API. Hopefully it could be get into the Groovy Core distribution. It provides an alternative way to use messaging without running in the GroovyJMS execution context.

      Groovy SQL

      Possible JMS Usage

      Remarks/Comment

      Sql.newInstance()

      JMS.newInstance(jmsConnectionFactory)

      or just use new JMS()

      sql.eachRow

      jms.eachMessage("myQueue"){m-> }
      jms.eachMessage("myQueue", [within:100]){}

      m is a String, Map, byte[] (question)
      , Stream or Object

      jms.reply() could be used inside the closure

      reply is not implemented

      sql.firstRow

      jms.firstMessage("myQueue")

      return a String, Map, byte[] (question)
      , Stream or Object

      jms.onMessage("topic"){ m -> }
      jms.onMessage("topic", [durable:false]){}

       jms.reply() could be used inside the closure

      firstMessage() and onMessage() are not implemented

      sql.execute()

      jms.receive( fromQueue: 'myQueue', within:1000)
      { println it }
      jms.receive( fromQueue:['queue0','queue1'], within:1000, with:
      { println it})

      fromTopic and fromQueue could be used together
      fromQueue always call receiveAll (to be enhanced to take a parameter to return only 1 message)
      if fromQueue has more than one queue, it return all messages of all queues
      fromTopic is asynchronous durable subscription, if both fromQueue and fromTopic are used together, any immediately available messages in any fromQueue will return first, and new message will be delivered to the same with closure in a later time
      either use jms.receive([:]){ }  or jms.receive([xxx:yyy, with:{}]) ; the former override the later
      within is a per queue timeout interval, not total; if there are more than one queue, each are retrieved in sequence

      sql.executeUpdate()

      jms.send( toTopic:'myTopic', message:[key:value], replyTo:'')

      toTopic and toQueue could be used together
      toTopic and toQueue support collection

      Similar to Sql, fine-grained control over connection/session could be done by passing in a JMS Connection or Session in the JMS.newInstance(), and user has to close the session/connection themselves

JMS Connection Factory

To use GroovyJMS, you need to decide which JMS implementation you'll use. There are several options:

  1. use the default in-memory, not-persistent ActiveMQ broker and connection factory, this is created by the ActiveMQJMSProvider class. Notice that the ActiveMQJMSProvider will start a ActiveMQ broker if it is not existed already, and will add a "vm://localhost" transport connector URL if not existed. In this case, the syntax is as simple as:
  2. Provide a JMSProvider by
    1. specific a "groovy.jms.provider" system property that point to a class that implements groovy.jms.provider.JMSProvider
    2. set a JMSProvider to the JMS.provider static variable, e.g.
  3. Provide Connection Factory or Connection in runtime. it is the most recommended approach. You may utilize your JEE container or dependency injection framework to inject the required JMS resources to your class, and support the connection or factory to GroovyJMS.

Unsupported Features or Limitation

  • nested usage is not supported yet. you may still use the lib in nested manner but you have manage the Connection and Session carefully.
    • For example:
    • you are recommended to avoid nestled usage. If you use it, try to use a multiple connection.
  • There is no support for transaction. all messages are auto-committed
  • No labels