Legacy JMS Input and Output Adapters

By default, the JMS adapters only try to connect to a JNDI or JMS server one time before giving up. However, you can configure the adapter to retry the connection a certain number of times at set intervals before giving up. To do this, set the server-num-retries and server-reconnect-interval attributes of the relevant <jms-server> section in the adapter's configuration file. The server-num-retries attribute controls the number of times the adapter will try to connect before giving up. The default value of this attribute is 0, which specifies no retries; the maximum value is MAX_INT. The server-reconnect-interval attribute controls the number of seconds to wait between connection attempts. The default value is 30 seconds.

Note that these values apply to both the JNDI and JMS servers configured in this <jms-server> section.

This functionality, used in conjunction with the Command Input and Status Output ports described here, can be used to implement logic to fully control the adapter's connection logic to the JMS servers it is configured to use.

When the JMS Reader receives a message, it translates this message into a Tuple and when the JMS Writer receives a Tuple, it translates it into a JMS message. There are five JMS message types: MapMessage, TextMessage, BytesMessage, ObjectMessage and StreamMessage. The JMS adapters include built-in support for the first three of these; this support is described in this section.

The message translation class used by the adapter for a given destination is specified using its fully-qualified Java class name in the <destination> tag's message-to-tuple-converter attribute (for JMS Readers) or tuple-to-message-converter (for JMS Writers) -- see JMS Configuration File Elements for examples.

A JMS message consists of two primary pieces, a header and a payload (body). In addition, properties can be set on a JMS message.

By default, the JMS Embedded Adapters map the fields of a MapMessage to the fields of a StreamBase schema. The JMS Reader looks for entries in the payload of a MapMessage that have the same names as the fields of the StreamBase schema. The JMS Writer simply creates entries in the outgoing Message to match all the fields of the incoming StreamBase schema.

The JMS Embedded Adapters also provide facilities for handling other mappings, specified in the configuration file. For example, a name map can be used to map a field on a MapMessage to a field on a StreamBase schema that has a different name. Similarly, the fields in the header of a JMS message can be mapped to the fields of a StreamBase schema. In the same way, JMS properties can also be mapped to the fields of a StreamBase schema.

The JMS Reader consumes messages from JMS destinations. The manner in which these messages are acknowledged is configurable within the JMS Reader. The setting for the acknowledge mode can impact the performance of the reader.

The JMS Reader fully supports acknowledge modes of AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE. The reader also fully supports the use of TIBCO EMS' proprietary acknowledge mode, NO_ACKNOWLEDGE. Of course, use of this acknowledge mode implies that TIBCO's EMS message bus is being used with the reader. The JMS Reader only partially supports CLIENT_ACKNOWLEDGE, TIBCO EMS' EXPLICIT_CLIENT_ACKNOWLEDGE and Apache ActiveMQ's INDIVIDUAL_ACKNOWLEDGE; while there is no way for the StreamBase application to trigger an explicit acknowledgement of the message, if one of these modes is selected the adapter will wait until the tuple is fully processed by the application before acknowledging the message. This gives the application a chance to, for example, persist the message to ensure later retrieval if needed.

The acknowledge mode for a given JMS server is specified in the <jms-server> section of the configuration file, using the attribute <acknowledge-mode>.

Note also that the JMS Reader makes no effort to prevent or in any way handle the delivery of duplicate JMS messages. If a JMS server delivers the same message twice, the JMS Reader will simply consume it twice.

The JMS Writer will create JMS messages and deliver them to a JMS message bus. JMS messages can be delivered with either of two delivery modes, DeliveryMode.PERSISTENT or DeliveryMode.NON_PERSISTENT. The delivery mode for a JMS destination is specified in the destination section of the configuration file, using the delivery-mode attribute.

The semantics of JMS delivery modes is beyond the scope of this discussion. In general, a delivery mode of PERSISTENT implies a higher quality of service for the JMS destination. Some performance penalty is also implied, however. In particular, if a delivery mode of PERSISTENT is specified, and there are durable subscribers for the message, then the JMS message will need to be persisted before the JMS server can acknowledge the message producer.

The JMS Writer dequeues tuples from StreamBase streams, translates them into JMS messages, and routes them to JMS destinations. The adapter relies on two fields in the dequeued tuple to determine which destination on which JMS server to send the translated message. The two fields must be called __JMSServerName and __JMSDestinationName. These fields must contain the name of a configured JMS server and destination, respectively. These fields are optional if only one destination is specified in the configuration; they are required if the configuration specifies more than one destination (that is, more than one server or more than one destination in a single server).

When one of the JMS Embedded Adapters executes, it needs to connect to an executing instance of a JMS message bus. Typically, this bus will be from one of the JMS providers. In order to connect to the JMS provider's JMS bus, JAR files supplied by the JMS provider must be made available to the JMS Adapters. This is true whether the adapter is executing from within StreamBase Studio or at a command-line invocation of StreamBase Server:

Name: Use this required field to specify or change the name of this instance of this component, which must be unique in the current EventFlow module. The name must contain only alphabetic characters, numbers, and underscores, and no hyphens or other special characters. The first character must be alphabetic or an underscore.

Adapter: A read-only field that shows the formal name of the adapter.

Class name: Shows the fully qualified class name that implements the functionality of this adapter. If you need to reference this class name elsewhere in your application, you can right-click this field and select Copy from the context menu to place the full class name in the system clipboard.

Start with application: If this field is set to Yes (default) or to a module parameter that evaluates to true, this instance of this adapter starts as part of the JVM engine that runs this EventFlow module. If this field is set to No or to a module parameter that evaluates to false, the adapter instance is loaded with the engine, but does not start until you send an sbadmin resume command, or until you start the component with StreamBase Manager.

Enable Error Output Port: Select this check box to add an Error Port to this component. In the EventFlow canvas, the Error Port shows as a red output port, always the last port for the component. See Using Error Ports to learn about Error Ports.

Description: Optionally enter text to briefly describe the component's purpose and function. In the EventFlow canvas, you can see the description by pressing Ctrl while the component's tooltip is displayed.

There is only one required property for either of the JMS Embedded Adapters: its configuration file. Configuration of the adapter is fairly involved, and so is not accomplished through its properties, but rather through its configuration file. Keep in mind that just the name of the configuration file, rather than its path, should be specified in the property. The named file will be searched for using the path specified in the configuration for StreamBase itself.

There are also two optional properties to control whether the adapter should accept JMS connection/disconnection commands from the application and whether status tuples should be issued when JMS servers or destinations become available or unavailable.

The JMS Reader is similar to an input stream that gets its input from a JMS Message bus. As with an input stream, a Schema needs to be specified for the JMS Reader. The Schema used by the JMS Reader is specified in the Edit Schema tab of the Properties View in StreamBase Studio.

Here are some typical settings for connecting to JMS servers from TIBCO EMS, ActiveMQ, IBM WebSphere, and Solace Systems:

TIBCO EMS (using JNDI)

<jms-servers>
  <jms-server name="EMSServer" 
    provider-context-factory="com.tibco.tibjms.naming.TibjmsInitialContextFactory" 
    provider-url="tibjmsnaming://localhost:7222" 
    connection-factory-name="ConnectionFactory" 
    acknowledge-mode="NO_ACKNOWLEDGE"/>
</jms-servers>

ActiveMQ version 5.x (using JNDI)

<jms-servers>
  <jms-server name="ActiveMQServer" 
    provider-context-factory="org.apache.activemq.jndi.ActiveMQInitialContextFactory"
    provider-url="tcp://localhost:61616"
    connection-factory-name="ConnectionFactory"
    acknowledge-mode="AUTO_ACKNOWLEDGE"/>
</jms-servers>

IBM WebSphere Application Server version 6.1's Default JMS Implementation (using JNDI)

<jms-servers>
  <jms-server name="server1" 
    provider-context-factory="com.ibm.websphere.naming.WsnInitialContextFactory"
    provider-url="iiop://localhost:2809"
    connection-factory-name="jms/MyConnFactory"
    jndi-initial-context-builder="com.streambase.sb.adapter.common.jms.common.WASJNDIInitialContextBuilder"
    create-destinations="false"
    acknowledge-mode="AUTO_ACKNOWLEDGE"/>
</jms-servers>

Solace default JMS Implementation (using JNDI)

<jms-servers>
  <jms-server name="solaceJms" 
    provider-context-factory="com.solacesystems.jndi.SolJNDIInitialContextFactory"
    provider-url="smf://MyProviderHost:MyProviderPort"
    connection-factory-name="MyConnFactory"
    acknowledge-mode="AUTO_ACKNOWLEDGE"
    jndi-security-principal="MySecurityPrincipal"
    jndi-security-credentials="MySecurityCredentials"
    jndi-initial-context-builder="com.streambase.sb.adapter.common.jms.common.SolaceJNDIInitialContextBuilder"
    username="MyUsername"
    create-destinations="true"
    password="MyPassword" >
    <jndi-extra-properties>
      <extra-property name='Solace_JMS_OptimizeDirect' value='false'/>
      <extra-property name='Solace_JMS_VPN' value='MyJmsVpn'/>
    </jndi-extra-properties>
  </jms-server>
</jms-servers>

The JMS configuration file is in XML format. For reference, the following listing shows the complete set of valid elements for the JMS input configuration file.

<?xml version="1.0" encoding="UTF-8"?>
<sb-jms-adapter-config
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:noNamespaceSchemaLocation="http://www.streambase.com/schemas/sbjmsreader/"
	adapter-class="com.streambase.sb.adapter.jms.enqueue.JMSReader"
	>
                                                                               
  <!--
  
  	NAME MAPS

    By default, this adapter will match JMS fields with StreamBase fields 
    when they share the same name.
    This behavior can be overridden with a 'name map'.  A name map is used 
    to associate a JMS field and a StreamBase field when they do not share 
    the same name.
    
    A set of name maps can be specified.  Each configured destination can 
    use a different name map.  Name maps are themselves named and are 
    referred to by name.
    
  -->
  <name-maps>

    <name-map name="MyNameMap">

      <!--
      	A name map consists of a set of mappings, each associates a JMS 
        field with a StreamBase field that has a different name.
      -->
      <mapping jms-name="symbol" sb-name="ticker_symbol"/>
      <mapping jms-name="bid" sb-name="value"/>
      
    </name-map>

    <!--
      A second name map.
    -->
    <name-map name="MSFTConversion">
    
      <mapping jms-name="MSFTsymbol" sb-name="ticker_symbol"/>
      
    </name-map>
  </name-maps>

  
  <!--
    If many destinations use the same name map, it may be convenient to 
    specify a default.
  -->
  <default-name-map>MyNameMap</default-name-map>



  <!--
  
  	JMS HEADER MAPS

    A JMS message is delivered with a set of standard JMS header fields.  
    Header fields can be mapped to StreamBase fields using a 
    jms-header-map.

    A set of header maps can be specified.  Each configured destination
    can use a different header map.  Header maps are named and are 
    referred to by name.
    
  -->
  <jms-header-maps>

    <jms-header-map name="MyHeaderMap">

      <!--
      	A JMS header map consists of a set of mappings.  Each mapping 
      	associates a JMS header with a StreamBase field.  The value of the 
      	JMS header field will be written to the StreamBase field.
      -->
      <mapping jms-name="JMSTimestamp" sb-name="jms_timestamp"/>
    </jms-header-map>
  </jms-header-maps>

  <!--
  	If many destinations use the same header map, it may be convenient to 
  	specify a default.
  -->
  <default-jms-header-map>MyHeaderMap</default-jms-header-map>


  <!--
  
  	JMS PROPERTY MAPS

  	Either a JMS provider or a message creator can add properties to a JMS 
    message.  Properties can be thought of as provider or user defined 
    headers.

  	As with headers, a map is used to associate a property with a 
    StreamBase field.  A mapping associates a JMS property with a 
    StreamBase field, causing the value of the property to be written to 
    the StreamBase field.

  	A set of property maps can be specified.  Each configured destination 
    can use a different property map.  Property maps are named and are 
    referred to by name.
    
  -->
  <jms-property-maps>

    <jms-property-map name="MyJMSPropertyMap">

      <!--
        A JMS property map consists of a set of mappings.  Each mapping 
        associates a JMS property with a StreamBase field.  The value of 
        the JMS property will be written to the StreamBase field.
      -->
      <mapping jms-name="StartTime" sb-name="start_time"/>
      <mapping jms-name="EndTime" sb-name="end_time"/>
    </jms-property-map>
  </jms-property-maps>

  <!--
    If many destinations use the same property map, it may be convenient to 
    specify a default.
  -->
  <default-jms-property-map>MyJMSPropertyMap</default-jms-property-map>



  <!--
  
  	TIMESTAMP FORMATS

  	StreamBase represents a timestamp as a type 
       com.streambase.sb.Timestamp.

  	Fields, properties or headers delivered in a JMS message may represent 
    timestamps, but they will not be of this type.

  	A timestamp format can be used when a JMS field, header, or property 
    delivers a timestamp that is represented as a string.  The timestamp 
    format is used to specify the format of the string so that it can be 
    translated to a com.streambase.sb.Timestamp.

  	A set of timestamp formats can be specified.  Each configured 
    destination can use a different timestamp format.  Timestamp formats 
    are named and are referred to by name.
    
  -->
  <timestamp-formats>    
    <timestamp-format name="MyTimestampFormat" 
                      format="MM/dd/yyyy hh:mm:ss aa"/>
  </timestamp-formats>

  <!--
  	If many destinations use the same timestamp format, it may be 
    convenient to specify a default.
  -->
  <default-timestamp-format>MyTimestampFormat</default-timestamp-format>



  <!--
  
  	DEFAULT DELIVERY TIME FIELD

  	It may be useful to mark a StreamBase tuple with a timestamp indicating 
    when the tuple was delivered to the StreamBase application.

  	The delivery time attribute is used to specify a field on the 
    StreamBase tuple to mark with the delivery time.

  	If many destinations set the same delivery time field, it may be 
    convenient to set a default.
    
  -->
  <default-delivery-time-field>arrival_time</default-delivery-time-field>



  <!--
  
  	DEFAULT MESSAGE TO TUPLE CONVERTER

  	This adapter converts JMS messages to StreamBase tuples.  
    The software responsible for this functionality is represented by an 
    interface, 
    com.streambase.sb.adapter.common.jms.enqueue.FromJMSMessageConverter.
    A default implementation of FromJMSMessageConverter is supplied.

  	It may be that a custom implementation of FromJMSMessageConverter is 
    needed however.  For each configured destination, it is possible to 
    specify a custom implementation of FromJMSMessageConverter.

  	If many destinations set the same FromJMSMessageConverter, it may be 
    convenient to set a default value.
  -->
  <default-message-to-tuple-converter>com.streambase.sb.adapter.common.jms.enqueue.DefaultFromJMSMapMessageConverter</default-message-to-tuple-converter>


  <!--
  
    DEFAULT CONVERTER CUSTOM SETTINGS

  	If many destinations set the same converter custom settings, it may be 
    convenient to set a default.
    
    Because the format of this string is arbitrary, some care should be taken to keep it
    valid within this XML file. For example, embedding a "greater than" sign may require
    the use of "&gt;"
    
  -->
  <default-converter-custom-settings>Insert your default custom settings here</default-converter-custom-settings>


  <!--
  
  	JMS SERVERS

  	This adapter subscribes to messages from one or more JMS message buses.
    Each JMS message bus is configured using a jms-server element in this 
    config file.
    
  -->
  <jms-servers>

    <!--
    
      JMS SERVER
      
      A JMS server is configured using the attributes of the jms-server 
      element.
      
      Two different sets of attributes are supported, one for connecting to a
      JMS server using JNDI, and one for connecting to a JMS server without using JNDI.

      Name is used in either case.
      	- name:  Each JMS server is named and can be referred to by name.
      	  This parameter is required.
      	
      To connect to a JMS server using JNDI (LDAP, etc.) an initial JNDI Context is instantiated
      using values for Context.INITIAL_CONTEXT_FACTORY and Context.PROVIDER_URL (among others; see below.)
      Values for these are specified as attributes on the JMS server element:

      	- provider-context-factory:  This attribute is used to specify a 
          value for Context.INITIAL_CONTEXT_FACTORY.
      	  This parameter is required.
          
      	- provider-url:  This attribute is used to specify a value for 
          Context.PROVIDER_URL.
      	  This parameter is required.
          
      	- connection-factory-name:  A connection factory to be looked up
      	  by name via a JNDI lookup. This will then be used to construct
      	  the connection object.
      	  This parameter is required.
          
      In addition, a host of optional settings are available to help set up the proper
      InitialContext for JNDI lookups:
    
        - jndi-security-principal:      Corresponds to javax.naming.Context.SECURITY_PRINCIPAL
        - jndi-security-credentials:    Corresponds to javax.naming.Context.SECURITY_CREDENTIALS
        - jndi-security-authentication: Corresponds to javax.naming.Context.SECURITY_AUTHENTICATION
        - jndi-security-protocol:       Corresponds to javax.naming.Context.SECURITY_PROTOCOL
        - jndi-authoritative:           Corresponds to javax.naming.Context.AUTHORITATIVE
        - jndi-dns-url:                 Corresponds to javax.naming.Context.DNS_URL
        - jndi-referral:                Corresponds to javax.naming.Context.REFERRAL
        - jndi-initial-context-builder: Full-qualified name of the Java class implementing
                                        com.streambase.sb.adapter.common.jms.common.JNDIInitialContextBuilder,
                                        which is responsible for creating the JNDI InitialContext object
                                        based on the settings described here.
        - jndi-extra-properties:        Defines additional properties that may be required
                                        beyond those defined in javax.naming.Context.
          
        This latter node is expected to contain an arbitrary number of sub-nodes
        named 'extra-property' with attributes named 'name' and 'value'.

      To connect to JMS WITHOUT using JNDI, you must specify the name of a class implementing
      javax.jms.ConnectionFactory, as well as the URL to use:

      - connection-factory-class:  The name of the connection factory class to instantiate.
        It is assumed that this class implements a constructor taking one String parameter
        that represents the URL of the JMS broker.
      - connection-factory-url:  The broker URL to pass to the connection factory at construction time.

      The following optional settings are available to help create and manage a connection to JMS:
              
        - client-id:  If desired, a specific ClientID value may be set
          on the connection. This will result in the adapter
          calling javax.jms.Connection.setClientID() with the supplied
          value.
          
        - subscriber-name: If specified, causes a durable subscription
          to be made/used with the specified subscriber name.  Valid
          only when used in conjunction with destinations that are
          Topics.
          
        - username:  The username to use when connecting to JMS.
        
        - password:  The password to use when connecting to JMS.
          
      	- acknowledge-mode:  The mode that is used to acknowledge JMS 
          messages.  Defaults to AUTO_ACKNOWLEDGE.  Other values include:
              - DUPS_OK_ACKNOWLEDGE
              - CLIENT_ACKNOWLEDGE
              - NO_ACKNOWLEDGE (TIBCO EMS-specific)
              - EXPLICIT_CLIENT_ACKNOWLEDGE (TIBCO EMS-specific)
              - EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE (TIBCO EMS-specific)
              - INDIVIDUAL_ACKNOWLEDGE (Apache ActiveMQ-specific)
          
      	- create-destinations:  Whether destinations should be created or 
          looked up in JNDI.  If supported by the JMS provider, destinations 
          can be created even if they exist.  Creating destinations is faster 
          than looking them up in JNDI.  By default destinations are 
          created.
          
      	- cache-destinations:  Whether destinations should be cached once 
          created. The default value of "true" offers better performance,
          however if you are creating thousands of destinations caching them
          may adversely affect your memory footprint. 
          
      	- use-topics:  If this attribute is true, then destinations will be treated as 
          Topics, otherwise they will be treated as Queues.  The default is 
          to treat destinations as Topics (i.e. "true").
          
        - server-num-retries:  The number of times the adapter should retry
          to connect to the JMS server (and/or the JNDI server) before giving up.
          Negative values are not allowed, and the highest allowed value
          is 2147483647 (Java's Integer.MAX_VALUE).

        - server-reconnect-interval:  The number of seconds to wait between each
          connection retry.

        - destination-monitor-interval:  The number of milliseconds to wait between
          attempts to monitor the health of subscribed destinations on this server.
          A value of 0 (which is the default) indicates no monitoring should be attempted,
          and so the StreamBase application will never be notified of
          availability/unavailability of destinations on this server.

        - connection-builder:  The fully-qualified name of a class that implements
          com.streambase.sb.adapter.common.jms.common.ConnectionBuilderInterface, which
          will be responsible for creating and initializing JMS Connection objects.
          If this parameter is not specified, the adapter's default implementation
          will be used. You may use the "custom-settings" attribute (see below) to
          pass along arbitrary strings to this class.

        - custom-settings:  An arbitrary string passed verbatim to the implementer
          of the CustomConnectionBuilder interface (see the connection-builder
          attribute above.)

      DEFAULT VALUES FOR JMS-SERVERS SECTION
    
      It may be convenient to set default values for some of the settings above. These will be
      used for every jms-server entry below unless noted otherwise.
    
      Available default settings are:
    
        - default-server-num-retries
        - default-server-reconnect-interval
        - default-client-id
        - default-subscriber-name
        - default-jndi-security-principal
        - default-jndi-security-credentials
        - default-jndi-security-authentication
        - default-jndi-security-protocol
        - default-jndi-authoritative
        - default-jndi-dns-url
        - default-jndi-referral
        - default-connection-builder
        - default-jms-server-custom-settings
        - default-destination-monitor-interval
        - default-jndi-initial-context-builder
        - default-jndi-extra-properties

        This latter contains sub-nodes called 'extra-property', whose 'name' and 'value'
        attributes are passed to the JNDI InitialContext as additional environment properties.
        This can be useful when dealing with JNDI providers that require custom environment
        properties beyond those defined in the javax.naming.Context interface.
    -->
    
    <default-jndi-security-principal>MySecurityPrincipal</default-jndi-security-principal>

    <default-jndi-extra-properties>
        <extra-property name="DefaultSetting1" value="Value1" />
        <extra-property name="DefaultSetting2" value="Value2" />
    </default-jndi-extra-properties>
    
    <jms-server 
      name="EMS-SERVER" 
      
      description="This describes the JMS server"
      
      provider-name="TIBCO EMS"

      provider-context-factory="com.tibco.tibjms.naming.TibjmsInitialContextFactory" 

      provider-url="tibjmsnaming://localhost:7222" 

      connection-factory-name="GenericConnectionFactory" 

      acknowledge-mode="NO_ACKNOWLEDGE"

      create-destinations="true"

      server-num-retries="3"

      server-reconnect-interval="5"

      use-topics="true">

        <!--
        To connect to the server without using JNDI, specify connection-factory-class
        and connection-factory-url.
        -->
        <!--
        <jms-server name="tibcoServer2" 
            
                   create-destinations="true"
                   use-topics="true"

                   connection-factory-class="com.tibco.tibjms.TibjmsTopicConnectionFactory"
                   connection-factory-url="localhost"/>
        -->


      <!--
      These (optional) settings will be passed to the JNDI InitialContext as additional
      Context environment properties.
      This can be useful when the JNDI service provider requires custom properties in addition
      to the standard properties defined in the javax.naming.Context interface.
      -->
      <jndi-extra-properties>
          <extra-property name="Setting1" value="Value1" />
          <extra-property name="Setting2" value="Value2" />
      </jndi-extra-properties>

      <!--
      	The set of destinations on this JMS server that the adapter 
        subscribes to is listed here.
      -->
      <destinations>
      
        <!--
          Each destination is configured with a set of attributes.  A 
          default is provided where possible as there may be many 
          destinations.
          
          If an attribute is left unspecified for a destination, then the 
          default value of that attribute is used.  For example, if the 
          name map is left unspecified then the default name map is used.  
          If the attribute is left unspecified and no default is specified, 
          then the associated operation is not done.  For example, if no 
          name map is specified and there is no default name map, then no 
          name mapping is done.
          
            - name:  A destination is created or looked by name.

            - is-topic:  'true' if this destination is a topic, 'false' if
              it's a queue.

            - message-selector:  The message selector expression (if any) to
              use for this destination.
          	
            - name-map:  The name map used for this destination.  If 
              specified, the name map must be included in 'name-maps'.
              
            - jms-header-map:  The header map used for this destination.  If 
              specified, the header map must be included in 
              'jms-header-maps'.
              
            - jms-property-map:  The property map used for this destination.  
              If specified, the property map must be included in 
              'jms-property-maps'.
              
            - timestamp-format:  The string format used by timestamp fields 
              delivered by this destination.  The timestamp format must be 
              specified in the timestamp-formats section.
              
            - delivery-time-field:  The field on the StreamBase tuple that 
              will be marked with the delivery time.
              
            - message-to-tuple-converter:  The class used to translate JMS 
              messages to StreamBase tuples.  If message-to-tuple-converter 
              is not specified, then default-message-to-tuple-converter is 
              used.

            - converter-custom-settings:  This is a string that is passed verbatim to
              the specified message-to-tuple-converter. It allows implementers to pass
              arbitrary values to their converter. The implementing converter code is
              the sole responsible for parsing and interpreting this string. 
        -->
        <destination 
          name="topics.IN.MSFT"

          name-map="MSFTConversion"

          jms-header-map="MyHeaderMap"

          jms-property-map="MyJMSPropertyMap"

          timestamp-format="MyTimestampFormat"

          delivery-time-field="arrival_time"

          converter-custom-settings="ArbitraryKey=ArbitraryValue,AnotherKey=AnotherValue"

          message-to-tuple-converter="com.streambase.sb.adapter.common.jms.enqueue.DefaultFromJMSMapMessageConverter"

          is-topic="true"
        />

        <!--
          In addition to explicit destination definitions handled by the <destination> tags,
          a <default-destination> may be specified which will be used when creating new
          destinations (i.e. when the <jms-server create-destinations=true />).

          The syntax is the same as for the <destination> tag above except the 'name' attribute is ignored.

          At most ONE <default-destination> tag may be specified for each <jms-server>.
        -->
        <default-destination
          name-map="MyNameMap"

          jms-header-map="MyHeaderMap"

          jms-property-map="MyJMSPropertyMap"

          timestamp-format="MyTimestampFormat"

          delivery-time-field="arrival_time"

          converter-custom-settings=""

          message-to-tuple-converter="com.streambase.sb.adapter.common.jms.enqueue.DefaultFromJMSMapMessageConverter"
        />

      </destinations>
    </jms-server>
  </jms-servers>

</sb-jms-adapter-config>

The command input port may be used by the application to request connections or disconnections to a configured JMS server, or to pause or resume processing for a JMS destination.

If the adapter is configured to expose a command input port, its schema is expected to have the following fields:

Permitted values for the command field are the following (case is unimportant):

The status output port can be used by the application to receive tuples describing status events for configured JMS servers (connection and disconnection) and optionally for destinations (available or unavailable.)

If the adapter is configured to expose a status output port, its schema has the following fields:

Possible values for the status field are:

First, you must tell the JMS adapter what kind of destination you wish to create by adding a default-destination entry to your JMS server's destinations section in the adapter's configuration file. The syntax to this section is identical to that of regular destination entries, except that the name attribute is ignored. You must also make sure that the JMS server's definition includes a create-destinations="true" attribute:

<jms-servers>
  <jms-server name="myJMSServer" 
    provider-context-factory="..."
    provider-url="..."
    connection-factory-name="MyConnFactory"
    acknowledge-mode="AUTO_ACKNOWLEDGE"
    jndi-security-principal="MySecurityPrincipal"
    jndi-security-credentials="MySecurityCredentials"
    jndi-initial-context-builder="..."
    create-destinations="true"
    username="MyUsername"
    password="MyPassword" >
    <destinations>
      <default-destination name-map="MyNameMap" use-topics="true"/>
      <destination name="topics.test1" name-map="MyNameMap"/>
    </destinations>
  </jms-server>
</jms-servers>

The way endpoints are created dynamically at runtime depends on whether you wish to publish or subscribe to the new endpoint — in other words, it depends on whether you are using the JMS Reader or JMS Writer adapter.